PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:43 UTC (Wed) by dlang (guest, #313)
In reply to: PostgreSQL, OpenSSL, and the GPL by joey
Parent article: PostgreSQL, OpenSSL, and the GPL

in a way I'd love to see this go to court and see if dynamic linking by itself can be deemed to create a derived work.

to post comments

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 0:20 UTC (Thu) by gmaxwell (guest, #30048) [Link] (4 responses)

Sigh.

Your distributor relied on the license in order to create the CD containing the GPLed work and openssl. From then on out they were bound by the relevant licenses by virtue of the copying alone.

The legal definition of a derived work isn't especially relevant: If the GPL said that you could only use the software on a machine with no microsoft products, then thats the rule. You don't have to ask if the microsoft products are a derived work in order to answer questions about being able to use the licensed work itself.

The license can do whatever it likes, and your option and obligation is to not distributed the GPLed software if you are can't/won't meet the licensing requirements. So the relevant question is "what does the GPL require?"

The whole concept of derived works is a pure distraction for linking boundary questions when you're asking about someone who distributes _both_ the GPL and the non-GPL thing. The legal derived work boundary only matters when someone is claiming that they have no obligations under the GPL because they don't distribute the GPLed thing.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 0:14 UTC (Fri) by giraffedata (guest, #1954) [Link]

Your distributor relied on the license in order to create the CD containing the GPLed work and openssl. From then on out they were bound by the relevant licenses by virtue of the copying alone.

You've got this all turned around. A license doesn't restrict people; it permits them. You don't copy and then have to do what the license says; you meet the conditions of the license and then you have permission to copy. After you make that legally permitted copy, the license is irrelevant.

Some publishers extend their control with a contract (EULA): in exchange for a license to copy, the copier promises never to use Microsoft products in the future. Now the publisher can enforce that contract -- not the license. Some people believe a contract like that is formed whenever someone avails himself of a public license such as GPL. Some don't. But either way, the contract is quite distinct from the copyright license.

I agree with you that a copyright licensing scheme for readline could stop people from shipping readline in a package with openssl to be dynamically linked, and do it without involving any rights over derived works.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 1:35 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (2 responses)

Careful here. GPL is a license, in that it allows you to do certain things that under normal circumstances you aren't allowed to do under the law. If the law says that just linking two binary blobs doesn't create a derivative work of either one, FSF can insist until they are blue in the face that GPL doesn't allow linking to non-GPL-compatible stuff on the theory that that creates a derivative, but you are allowed to do it anyway (by the law).

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 2:42 UTC (Fri) by gmaxwell (guest, #30048) [Link] (1 responses)

You appear to be perpetuating a common misunderstanding.

Absent the permissions provided in the license you are not legally permitted to do much with the covered work. If you want to perform some act reserved to the copyright holder (like copy the covered work with or without combining it with other things) then you may legally do so only by the good graces of the license.

This is the relevant hook. Quoting v2, "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or _distributing the Program_ (or any work based on the Program), you indicate your acceptance of this License to do so, and _all its terms and conditions_ for copying, distributing or modifying the Program or works based on it." (em mine)

The FSF can't stop you from wearing party hats*, but they can write a no party hat condition into their license, and your only options are to decline to practice the copyright-exclusive acts (distributing the software), eschew party hats, or violate copyright (at your own legal peril).

Moreover, if it _didn't_ work this way if the license continued to permit copying when you violate its terms then the license could have no useful effect except creating a blanket permission. The GPL makes _many_ such requirements of normally permitted activities conditions for enjoying the license, e.g. offering the source code.

In the few cases where someone might link to GPLed code without ever subjecting themselves to the requirements of the GPL (e.g. by not distributing the covered work or engaging in other copyright-protected activities, including creating derivatives in the strict legal sense) then they can potentially get away with it. An example of this might be a proprietary software vendor linking a GPLed system library which they are careful to never distribute themselves.

*[A silly example; I would expect a court to invalidate such a term as having no meaningful connection to the licensed activity. The same could not be said about rules about how the software was employed]

PostgreSQL, OpenSSL, and the GPL

Posted Feb 22, 2011 17:16 UTC (Tue) by nye (subscriber, #51576) [Link]

>You appear to be perpetuating a common misunderstanding.

You should re-read the post to which you are replying - I believe you've entirely misunderstood what vonbrand wrote.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 15:56 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

It can't. In a similar fashion, working around dynamic linking with some technical trick can't "un-derive" one work from another either. In short, the technical arcania may not be massively relevant to the derivation question.

E.g. Google have put Bluez in Android behind a DBus IPC interface, because Bluez is GPL and they wish to insulate proprietary applications that build on Android's Bluetooth stack from the GPL. While it may technically succeed in isolating such apps from the bluez library /API/, legally it need *not* change the fact that codes X,Y,etc are dependent on code Y.

At least, that's the legal advice I'm aware of from the corporate counsel of a different, large technology counsel, in a very similar situation code/IPC wise.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 28, 2011 9:29 UTC (Mon) by salimma (subscriber, #34460) [Link] (2 responses)

In the Android case, wouldn't BlueZ be considered part of the system libraries, in which case it's a moot point whether apps using it indirectly through the DBus layer are considered derivatives or not?

PostgreSQL, OpenSSL, and the GPL

Posted Feb 28, 2011 9:52 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Perhaps. Maybe Google lawyers are being extra cautious. It doesn't really hurt them to do that.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 28, 2011 11:33 UTC (Mon) by paulj (subscriber, #341) [Link]

The system library exception exists to allow GPL apps to link to proprietary apps. It does not apply in the opposite direction, i.e. it can not give proprietary apps permission to derive from a GPL work. IMU.