This is rather a theoretical interest for me for now (what else to do Friday evening) , but I see how it can be used in current dual-licensed mixed open / closed source storage engines MySQL world.
So problem is:
Let’s keep MySQL aside for simplicity and imagine we have fully open-source GPLvX licensed “MoonOffice” software. MoonOffice uses libsupercompress library which also distributed under GPL, and provide two functions: “superCompressFile”, “superDecompressFile”. MoonOffice can be both statically or shared linked with this library. This all fine.
Now imagine one provides library libquickcompress, which is closed sourced, available only in binary formats .so and .la, but the license on it is “use it as you want, link it with whathever you want, distribute it as you want”. Of course library also exports two functions “superCompressFile”, “superDecompressFile”.
Now questions: can we link our GPLed “MoonOffice” with libquickcompress ? Can we distribute binary build of MoonOffce linked with libquickcompress ? What is license of final binary ?
May be it is simple question and answer is obvious, but I am not sure what is correct answer.
I am not a lawyer, but I believe the answer is: No, you cannot link to libquickcompress.
From the GPL faq:
I’d like to modify GPL-covered programs and link them with the portability libraries from Money Guzzler Inc. I cannot distribute the source code for these libraries, so any user who wanted to change these versions would have to obtained those libraries separately. Why doesn’t the GPL permit this?
There are two reasons for this.
First, a general one. If we permitted company A to make a proprietary file, and company B to distribute GPL-covered software linked with that file, the effect would be to make a hole in the GPL big enough to drive a truck through. This would be carte blanche for withholding the source code for all sorts of modifications and extensions to GPL-covered software.
Giving all users access to the source code is one of our main goals, so this consequence is definitely something we want to avoid.
More concretely, the versions of the programs linked with the Money Guzzler libraries would not really be free software as we understand the term—they would not come with full source code that enables users to change and recompile the program.
Pat,
OK, thanks.. that’s understood.
What about
LD_PRELOAD=libquickcompress moonoffice
or we load library which defined from user input.
moonoffice –userPassedLibrary=libquickcompress
…
dlopen(userPassedLibrary).
…
?
Vadim: It seems you are trying to find not the obvious answer, but to see how far you can push the limits:
Obviously from the GPL it follows you couldn’t distribute the no-source library with the GPL’d MoonOffice. But if there are 2 independent compression libraries that both provide the same compression functions, then it is not as such forbidden to use the second one with the GPL’d MoonOffice. For instance, suppose that on the popular Unix operating system Lunaris, the libquickcompress is commonly found as a “standard” library. In that case it is not wrong for the MoonOffice to use it – as long as it can be shown that primarily it depends on the GPL compatible libsupercompress library and uses that on other platforms. (No reference, but this was a common statement when QT was not GPL.)
The Dual licensing answer of course is that since Moon Microsystems Inc owns all the rights to MoonOffice, they can also sell you a non-GPL license, which gives you right to use libquickcompress without any doubts, and avoid this question altogether.
As far as I know, the answer is still no.
Basically, if you have some GPL code, you cannot link to non GPL code *at all*.
There is one exception in that you *are* allowed to link to “common system libraries”. So if you want your GPL code to run on, say, Windows XP, you’re allowed to compile in dependencies on the WIN32 API (since that’s considered a system library).
So if libquickcompress reaches a point where most linux distros distribute it as a blob (like some drivers), then I think you’d have a pretty good argument that its a system library and hence you can link to it.
Long as that’s not the case though, I’m fairly sure you’re not even on an edge case here. The GPL is reasonably clear that linked to non-GPL code is a no-no.
When you get down to it the GPL is trying (via licensing) to ensure that any piece of code released under the GPL remains fully usable under the GPL. A piece of free (GPL) software that requires a commercial (non GPL) library for full functionality isn’t really free (at least not by the FSF’s definitions).
Personally I’ve never been a big fan of the GPL, my thinking being if I want to release my code, I should just release it and let folks use it (the BSD model) rather than trying to tell folks *how* they can use it, but that’s a religious war. Plenty of folks would disagree.
Pat,
I can’t say I agree with your second comment. As I understand GPL is about distribution, not about usage. Compile-time restriction makes sense for me, but runtime is not obvious.
How can I, as GPL code vendor, prohibit usage of my binaries with LD_PRELOAD ?
Having MoonOffice on my box I can start it with
LD_PRELOAD=tcmalloc moonoffice or
with LD_PRELOAD=closedMallocLibrary moonoffice.
GPL license does not prohibit for me as for end user to-do that.
Henrik,
Yes, I am pushing limits… I want to understand restrictions.
Prohibiting the *use* of non-GPL code with GPL code on an individual’s machine if they’re not redistributing anything strikes me as a pretty core violation of freedom 0.
Cheers!
Luke
I’ll preface this once agan by saying: I am not a lawyer. It seems to me though that you’re trying fairly hard here to find a way to circumvent the intent of the GPL on the grounds that, in this particular case, the implications of the license are kind of silly and maybe even counterproductive to the ultimate goal of the GPL (promiting free software). From my understanding of copyright law though, that’s kind of irrelevant. What matters in these case is what a “reasonable party” would take away from the reading of the license. In cases where reasonable parties might disagree on the meaning of a particular, you end up on court.
In the particular case of the GPL, it appears that its author’s view is that, yes, linking a non system library that isn’t GPL is, in fact, a GPL violation. They make exceptions for standalone programs sharing data, but if you’re linked via an API, their position is, you’ve got a GPL violation. Now this might not, in fact, hold up in court, but that’s a secondary question to what the framers of the GPL intended.
From the FAQ:
If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module?
The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.
But you can give additional permission for the use of your code. You can, if you wish, release your program under a license which is more lax than the GPL but compatible with the GPL. The license list page gives a partial list of GPL-compatible licenses.
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
I don’t think anyone at Percona has any plans to try to stretch the GPL. I think this is more about understanding the interesting things we see people trying to do with storage engine licensing. It always seems people are trying to get the benefits of GPL while giving as little as possible in return. That’s my take on it anyway.
pat,
Indeed thank you for discussion, I am not lawyer either. As I said my interest becomes from closed-source engine world, we saw a lot of new engines on MySQL CE which will go as closed.
And I think I am not about stretch GPL, but contrariwise actually.
My interest is (fully theoretical for now) if we are able to make OpenSource GPL utility which will work with some closed engines using some API. From your words it becomes we can’t make this utility as GPL, which I personally think is awkward. Why GPL does not allow me to distribute brand new code under GPL license. It contradicts with goal – promoting free software. It seems it even forces me to choose different, maybe closed license.
Again, I am not arguing with you and not saying you are wrong or right, thank you for sharing insights!
Vadim – The Stored Engine is indeed very interesting topic.
This is exactly the case of open interface which multiple libraries implement – same as with compression library you have mentioned.
However to my knowledge all commercial storage engine vendors are getting commercial MySQL License rather than charging for plugin for GPL version.
I do not know if this is “have to” thing or it is just easier to buy the license and sell the set instead of providing such combination.
Vadim,
“LD_PRELOAD=tcmalloc moonoffice or
with LD_PRELOAD=closedMallocLibrary moonoffice.
GPL license does not prohibit for me as for end user to-do that.”
Right, so the end user can do pretty much anything with GPL code. However, it is worth pointing out that if your MoonOffice distribution actually contains a start script that does that for the user, then you are actually distributing a GPL application that (run-time) depends on a closed library.
Since we slipped into discussing MySQL engines and Percona now, suppose you create Xtrabackup to make backups of GPL MySQL and GPL InnoDB and GPL some other storage engines. My completely non-legal advice is that
– this can technically be run against an OEM licensed version of MySQL and InnoDB, and neither Percona or Oracle or Sun has done anything wrong if that happens.
– If you distributed GPL’d Xtrabackup together with an OEM licensed version of MySQL and InnoDB, then that might be a problem. (“Might”, since they are not actually linked together, but probably is a problem cause clearly they depend on each other.)
As far as I know all storage engine vendors do have a commercial MySQL license. The fact that it is also technically possible to load them as plugins into a GPL’d version of MySQL shouldn’t be a problem, since that is done by the end user and the producer of the engine would always use a properly licensed non-GPL binary. The interesting question would be if the GPL and OEM branches of mysql were to diverge a lot, with GPL version containing code not owned by Sun (Oracle) then loading a non-GPL plugin into a GPL’d version of MySQL could infringe rights of 3rd party contributors. But this is not the situation today.
LD_PRELOAD seems to be a bit odd, since then you distribute the launcher script which does that, maybe it’s a problem. What I am not sure, what can happen if you used dlopen() so there is _NO_ strict linking, no static linking, no LD_PRELOAD thing or anything, your software does this in runtime, so it’s not pre-load linking, at compile time, or even by that LD_PRELOAD thing, and it’s even optional, no strict dependency.
The GPL authors *seem* to be taking the position that it doesn’t really matter how you link to a GPL program. Rather what matters is the degree of data sharing. If both programs, for example, share a memory space and pass data between them on something more sophisticated than the CLI, then the GPL authors seem to be taking the position that there’s really only one program.
If there’s really only one program, then the whole program has to be GPL or none of it can be GPL.
Now an actual lawyer (as opposed to me) could probably tell you if their legal theory is enforceable or not, but that does appear to be their position.
Note that the above is different from my personal preference e.g. I think that free software *should* be able to link to proprietary code if that’s what the user wants to do with it. There is, in my mind, a perverse irony in the fact that the GPL, designed to promote “free” software, actually restricts my rights as a user of that software far more so than, say the BSD licensing model.
If something is truly free, I should be able to do whatever I want with it.
Pat, the GPL doesn’t prevent you from doing what you want with code, so long as you’re not distributing it. All of the GPL provisions you refer to only kick in when you distribute the code. That might not help the Percona folks in what they’re doing, but if I write a module that links to GPL’d software, I am under no obligation to distribute its source or license it under the GPL if I’m not giving it out.
Cheers!
Luke
This has been an issue in Java land as we have wanted readline FOREVER….
rlwrap partially solve this:
http://utopia.knoware.nl/~hlub/rlwrap/
Various other proposals existed including recommending the use of BSD editline or readline and allow the user to configure their system and dynamically bind to each library.
Shipping with no readline enabled by default and then allowing the user to select a readline to use would work and fix this problem.
the LD_PRELOAD issue also works.
Another idea is to just contact the author and see if he can relicense. Often they don’t realize they’re preventing people from using their code.
Or….. do what I do, and write a BSD version which is better 😉
Hi Vadim,
I am a lawyer, and I represented the plaintiff in Maryanovsky v. Rabinovich (which was settled), which was similar to what you ask. Basically, there are two different questions: the first is a whether you’re allowed to link at all (with a separate installer for the libcompress) and the second is can you distribute a binary aggregation.
My belief, and what we claimed in the lawsuit, was distributing GPLed applications alongside with binary proprietary files are prohibited. The distribution and repackaging creates a new application that is more than mere aggregation, especially if it includes one installer (in that case they used a windows app) and it does not include the source code and license for the proprietary library.
The simple solution is to distribute the library in a separate installer, or as a separate package.
You can always buy a proprietary license from the “MoonOffice” software vendor that allows you to distribute it only in binary or purchase the LibCompress’ source code for GPLing it.
If you need any help, you have my email.
Ok,
Thank all for comments. My understanding now is “Do it BSD or commercial license and you are safe”.
I respectfully disagree with Baron’s comment: “It always seems people are trying to get the benefits of GPL while giving as little as possible in return. That’s my take on it anyway.” You have to consider the diversity of the market and the broader benefit to users. For example, should applications that run on Linux have to be open sourced? Should they have to pay a Linux tax? Either of these options would have severely hampered the growth of the Linux application market and, in turn, limited the growth of Linux. In fact, it is best for all that there be broad set of companies offering a spectrum of capabilities. This is what builds a vibrant ecosystem. If someone wants to enhance an open source application, where: (a) it is non-core to the operation of the open source app; (b) there are open source alternatives; then who is hurt? The users ultimately vote with their dollars/downloads.
To use the example of the storage engine, consider if the engine company licensed technology from a University. They may be UNABLE to distribute it in source code form. Or consider a company with VC funding, their VCs may require a return on investment that precludes an open source business model. Should those engines be unavailable to the MySQL community? Who does that help?
I understand that these companies are building on the shoulders of those who went before them. But didn’t the MySQL folks build on the shoulders of developers who were unpaid? When MySQL sold for $1B, did they pay royalties or a “tax” to those unpaid developers?
In the end, we need to put religious issues aside and ask ourselves what is best for the user community. Certainly we don’t want to build dependencies upon closed source within an open source application. At the same time a vibrant community requires non-vital extensions that can be distributed under a variety of licensing models. As these companies grow, they support the old adage: When the water rises, all the boats go up. Just as many successful Linux application vendors reinvest in Linux, many successful commercial MySQL vendors will reinvest in MySQL.
The real question is simple: Do you want MySQL to be a single monolithic free piece of software, or do you want it to be fertile soil for any number of solutions, free, commercial, whatever? In the end, if an extension doesn’t deliver sufficient value…don’t buy it.
Vadim,
I’m quite sure you can’t BSD a GPL application and release it. The GPL specifically requests that you release all the code under GPL. You can release your library under BSD, but then someone can’t GPL it as well.