Slashdot Mirror
GPLv2 Libraries — Is There a Point?
PiSkyHi writes "I understand that if I build an application that links with a library that is licensed under GPLv2, I must also make my application GPL2. I can see that value in this for an application. But for a library, what's to stop me separating my program into a GPLv2-compliant client app that talks to the rest of my (choose my own license) application?"
I think the point is that there are a bunch of wankers who want to impose the GPL on everybody, knowing that linking your code against it will infect your codebase. There's nothing wrong with using LGPL which allows linking and protects the openness of the library's codebase.
I think a reasonable test would be to ask: is my program still mostly useful even if the GPLd helper/plugin is removed (modulo the specific removed function)?. If so, then I think it could be argued that your program is NOT a derivative work and that the GPL helper is governed the same as, say, a GPLd user application bundled with a commercial Unix/OSX distro. Personally I don't think it should matter how exactly it communicates with your code - what makes launching a process any different from a function call here?
Conversely: artificially doing contortions with your software to move essential libraries out to a separate app is not only in bad faith, but it doesn't work around the license at all. And if you ever had to argue otherwise, anyone turning up your slashdot story would not probably work in your favor.
IMHO the GPL, even v3, needs some work to clarify this question and also to close the hole for the software-as-a-service industry to modify GPL code without reciprocating.
That unless you want to contribute to RMS's and a lot others' psychotic Gandhi-like fantasy of making it impossible to produce proprietary software because all libraries required for interoperability have been GPL'd one at a time, you do exactly what you propose.
My personal hope is that a couple of countries invalidate the GPL and effectively make it fair game to incorporate into any product. Retaliation is unlikely, and that would pretty much wipe out the crazy, megalomanic dream.
what's to stop me separating my program into a GPLv2-compliant client app that talks to the rest of my (choose my own license) application?
Umm... nothing?
If you're writing your application from scratch without using anybody else's libraries, you're free to release it under whatever license you like, even if it happens to talk to a GPL'd client plugin thingie, and even if you wrote that GPL'd client plugin thingie around somebody else's GPL'd library.
Why do you imagine that somehow there's a problem here?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
The point is that enhancements to the library stay LGPL. I did this myself. I needed to modify LGPL libraries for the purposes of my application. I modified the libraries, and I am redistributing them under the LGPL. My main application is distributed under BSD license, and uses the LGPL libraries. The libraries make perfect sense separately (and in fact, I have people using them for reasons unrelated to the application I built). I think that, out of courtesy, and probably out of need, you need to make sure that the libraries are available separately.
This is exactly why the LGPL was created. Or sometimes you will have a GPL lib with the linking or classpath exception. You will find most libs are licensed under these, or even more permissive terms.
Therefore, if the lib in question is explicitly licensed under normal GPL, it's the author's wish that any apps that use it must be GPL compatible. I think it's only fair to follow the author's wish.
Doesn't the license basically stipulate that you must release your code under the terms of the license? That doesn't necessarily mean you have license your code as GPL.
This is actually a common FUD discussion that occurs between developers who use MIT/BSD license for their code, and are afraid to link to GPL libraries because it might force them to release their code as GPL. I'm pretty certain that as long as their code is available under the same terms as GPL code, they can license their code however they wish otherwise. It just means if a GPL nut comes a knockin', they'll have to provide the code as if it was GPL'd.
Correct me if I'm wrong (and I often am).
This summary is posted under "News" but there isn't any news in the summary nor is there a link to any news. WTF?
With commingling, it will be hard for GPL zealots to discover that you are indeed violating the GPL but once they do (I do not know how they do it), just release everything and beg for forgiveness. By that time, you'll already have made your profit.
But remember: You'll not be able to put a price on the publicity all the "fracas" will generate.
I understand that if I build an application that links with a library that is licensed under GPLv2, I must also make my application GPL2
That is NOT correct.
The criteria is 'derivative work', not 'link to'. Linking is sometimes a rule of thumb in this area, but it isn't decisive.
Note that 'derivative work' is a legal term, not a technical one. So before you try to circumvent the GPL in this way, consult a lawyer.
http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL
It's not a direct link, but nonetheless you should strive for independence of that functionality. Otherwise you are trying to comply with the letter of the law, but it may not be enough.
Quite aside from the legal meaning of the GPL, you could always ask the authors what they intended. If they want to prevent proprietary applications from using the library, as promoted by , that should influence your decision.
IMO, if the internals of your application are dictated by a GPL'd library -- *regardless* of how that library is linked, integrated, called, or plugged in -- your application is a derivative work. To separate them, put the library aside. Do a proper design. Gather scenarios you need the plugin to support. Document them. Write a new API. Document it. Collect some alternative libraries. Verify that you were not unduly influenced by the GPL'd one.
Or, you know, GPL the application.
Pardon, fumbled the link.
Why you shouldn't use the Lesser GPL for your next library
The problem is that there are plenty of zealots that will tell you that incorporating any GPL-licensed component in any way immediately forces the entire body of work to be released under GPL.
This can be interpreted at various times to include static linking, dynamic linking, linkage via any sort of invocation such as exec, RPC, and any other sort of connection between two pieces of code. What is the "right" answer? It isn't all that clear. It can be a matter of intent or of benefit. If the developer is benefiting from GPL code, then their project should be under GPL.
Further, what any competent lawyer will say is the objective is to avoid lawsuits. This means taking a proactive position to avoid getting into situations where some GPL zealot can potentially sue.
Essentially trying to play games with GPL can bring you into conflict with zealots. Some of these people have resources which allows them to file silly lawsuits without personally costing them a fortune. These are people to avoid coming into conflict with. So take the broadest possible interpretation of the GPL and live with it.
What you just described is not a problem. It reminds me of Samba. Microsoft never released a GPL'd SMB client. But others did hard work to reverse engineer it because the idea of not knowing how to log in an access files and print to windows servers, and pay for the license was abhorrent. This was their own data and equipment. (Remember that if the proprietary windows OS and smb client that came with it were the only way to log in, you paid twice... once for the OS and the "free" client, and once for each user or device that connected to the server.)
They could have released an open source client, or not kept the client protocol secret, or even made the proprietary client free per user and only charged users based on the number of concurrent connections to the file/print server. But they didn't. That's why it was reverse engineered. And further, now the samba project has expanded to emulate the server itself.
If you're considering making a closed server but open client, and the product actually becomes popular, you should expect that someone will make an emulator for the basic server functions eventually.
But I'm guessing the reason you want to use GPL'd software for the client is that it will help you develop your app better. And I'd also assume that after you think about the server-based per-user licensing model, you'll want to make the server more complex to deal with it. And when you make the server more complex, you'll look to see the best way to solve the problems you face, and you'll desire to use some open source library in the server too.
A lot of software users don't really care about such legalities.
In a world where there are millions of copies of bootleg Microsoft products and MacOS is coerced into running on non-Apple hardware, do you really think they will care about the subtleties of the various open source licenses?
Realistically, what are the odds you will do something that anyone will notice?
You can't make a linked wrapper library since the GPL wrapper would be GPL too. See: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLWrapper However it sounds like you are talking about a service based wrapper. Then I'd say it depends on how integrated your service wrapper is with your main program. If you use separate processes but lots of IPC and shared memory then I'd think you app is to tightly integrated making it a derived work. If you make a network based service then I'd say you are legally clear even if you'll probably piss off the library author. See: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#NFUseGPLPlugins You could also make your app GPL but put a lot of the functionality in non-free plugs, see: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#FSWithNFLibs Of course you could also just release you app as GPL and not worry about it. What is stopping you from using the GPL?
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
Not only is the GPL not specific on this issue, but it is unclear whether a clear license restriction on linking would even apply. Imagine if RMS and Linus had their way, and the author of an application could not only restrict distribution, but linking as well. Microsoft could legally prevent people from writing apps and drivers for their OS. Homebrew for restricted systems would actually be illegal. Would it be legal to write compatible libraries?
The great thing about shared libraries is, you don't have to distribute them, and therefore are not bound (AIUT) by their distribution licenses.
You obviously don't know much about Linus to include he and RMS on the same side of a licensing issue.
The whole idea of "linking" is too specific to a technology or architecture. It assumes that some code is "compiled" into some form of library and the functions become available through a "linking" process during the build.
What if I call functions in my library over SOAP? The application is still "linked" to a service ("library"), but using that logic a web browser would have to be GPLed if you access any GPLed web server.
RMS and others, (The community) possibly are there to stop you.
Probably some people have some creative interpretations of what it means to link against a GPL library, also. To call such things at least a gray area if not outright violations.
If/when they find out, they might point to your software as an example of bad practice, or put you in the "GPL Violations hall of shame", or some such.
This is especially interesting with respect to scripting languages... If I write a PHP script that utilizes mysql_* function calls of PHP, which can only be invoked when PHP has been linked against the Mysql Client library....
Is my PHP script essentially linked against the GPL'ed mysqlclient library, and therefore, (if I distribute my PHP script commercially without source) a GPL violation?
He, disguised as a rotund portly beast by the name of Richard Milhouse Stallman, fights the never ending battle for truth, justice, and the commie way !!
Isn't this what NVIDIA does with it's kernel drivers? I'm surprised no one has mentioned this yet... Rob.
RMS and Linus disagree on a lot of things. That does not mean that they disagree on everything. Specifically, they both agree on what I said above.
You should do some actual research before spoiting your "I know something therefore I know everything." Linus often says that Linux drivers must be GPL. RMS (and the FSF FAQ) says that only GPL applications are allowed to link against GPL libraries.
Here are some cherry-picked Linus quotes about the FSF, RMS and the GPL, pulled from here.
Disagreement and thinking that the FSF is controlling and putting its fingers where they don't belong is _not_ misunderstanding. It's just not "blind and unquestioning obedience".
Their additions - whether they be "modules" or just the UI - do not, necessarily, fall under the GPL. (Yes, there have been discussions about whether a kernel module is a derived work, but most of the time those discussions ended "Legally they aren't, even though I feel they should be")
If you want to use GPL for a library.. take a look at the LGPL...
You are correct. The answer is no. If the LGPLed library dynamically calls the GPLed library, then it is the FSF's position that the LGPLed library is a derivative of the GPLed library, and thus the work as a whole may only be distributed under the GPL. Please see this section of the FAQ:http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper.
For your specific requirements, I'd advise touching base with them - they have an advice service for these types of questions.
Actually, you wouldn't have to make your program GPL2, you would only have to make it compatible with GPL2. Which usually means GPL2 or something even more liberal like BSD. And only then of course, if you distribute.
Try actually reading the GPL license instead of making things up.
Too many people just quote hearsay and *think* that they know the GPL, and they're wrong. You're one.
Reading RMS's comments isn't enough either. You actually have to read the goddamn license, not just repeat hearsay, regardless of source. Much of what RMS says is just wishful thinking, and is not what Eben Moglen actually wrote into the license.
IANAL, but I wrote on copyright law for my discertation.
I believe the issue is not whether any inclusion of GPLv2 code forces you to make your code GPLv2, but rather that you cannot distribute the GPLv2 code with your (separate licensed) code (closed source?). You CAN however, NOT DISTRIBUTE THE GPLv2 code. You can release your code under any license you want, and distribute it any way you want. However, you will be forced to require a separate download & install on each computer that needs the library, of said GPLv2 library. You can build a simple downloader & installer for all the separate OSS libraries that runs when your software installer runs. This way, you are not distributing the GPLv2 code as part of your code, and there is no conflict.
I am a complete supporter of open-source mind-you, and hope you don't leech, but also contribute back to the project some patches and such.
As I see it, the point of OSS development isn't to force everyone to make their code OSS whether they like it or not, rather, it is to open-up code to many more testers and debugers than you could with closed source projects. You will always end up with a better quality software in OSS projects than in closed source. I feel that is enough for me. If you wish to produce a lesser quality software, I am happy that you do. Fore, once you create the market, I am happy to become an open-source competitor and take all your clients from you with better quality software. Infact, I ENCOURAGE YOU TO DO SO >:-D
IANAL
So I write a program licensed under the GPL, then someone else comes along and forks it, and makes it MIT/GPL. It is still mostly my work. Then Big Corporation comes along and takes the MIT licensed library, and creates a closed sourced, proprietary application from it.
I don't know if you are wrong or not, but I hope you are. That would be a serious loophole if it were true.
Perhaps you should do some research before making assumptions. There is a huge difference between pragmatism and ideology. Learn it.
This reminds me of our experience with mysql.. they changed the license of their drivers (the jdbc driver, in this instance) to GPL from LGPL a while ago, and also affirmed a legal position (at least in their marketing materials) that using the now GPL library would require any application dynamically linking/loading it to also be GPL, with the exception of being able to buy licenses to a separate non-GPL'd commercial instantiation of the library. (They also conveniently hired the guy who had been maintaining the previously freely useable LGPL version).
.war archive that was trivial to install (just copy it into tomcat/webapps or whatever (well, and run the database creation script to set up the tables for it) and it was good to go. After the license change he was unable to distribute a fully packaged pre-working .war file with the necessary drivers for client databases. (Oracle was propriatary, but free to distribute).. he had to write a specialized install script that the customer could use to unpack the .war, install the mysql jdbc driver, and repackage it, where the script required the client to affirm that they were using a legally licensed non-GPL version of the jdbc driver from mysql to be able to install/link it. This took the liability off of him ...The liability for having the temerity to want to talk with a basic software infrastructure service (such as a sql server), without GPL'ing his little niche app.
In theory, of course, someone else could re-invent the wheel and create another fully LGPL JDBC driver for mysql.. (I was ever-so-mildly tempted to do start work on that myself, out of spite and irritation, but didn't have the time).
Needless to say, after talking to the lawyer we had to switch our entire infrastructure over to postgresql. On the bright side, I found that I rather preferred postgres as a more comprehensive and functional sql anyway. (No more having to do manual tricks for multi-merges, etc). Still, it seemed like very bad faith to switch the license like that right out from under people who had already been using it, all in the hopes of further monetizing mysql. (Yes, the earlier license applied to the old versions of the driver... which happened not to work properly with newer versions of mysql).
I once talked to someone else else who makes a a bit of money on the side selling some piece of booking software. Unfortunately for him, almost half his clients were deploying his software in mysql shops. His software was a drop-in
I'm all for the GPL. I love it! I've used it myself in a few things I've developed. I love all the good it's brought, etc, the idea of openness, a publishing and peer-reviewed manner of developing code, all that.
But I still find it very obnoxious to make a piece of library glue GPL. That's exactly what the LGPL is there for. Logically, it's not a derivative work of mysql if you use it for processing sql transactions (making no modifications or redistributions of it of any kind) any more than a file you create in the gimp is a derivative work of the gimp.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
Perhaps you should pay attention. Your dribble has absolutely nothing to do with the topic at hand.
I've written a library which can be used fine without any GPL libraries but I wanted to add an extension that was essentially provided by an existing GPL library. So all I did is write a secondary library which links with my my original (non GPL) library and also the GPL library. I'm fairly confident all I have to do is license the second library under the GPL. It's clear my original library isn't a derived work of the GPL library (it doesn't even link with my secondary library nor the GPL library). Whilst the term "derived work" is a fairly legal term it isn't necessarily ambiguous or confusing to apply in the real world. I would think that the test "can my work operate in any form without the GPL work" is a fairly easy test to apply with regards to libraries and linking.
It's a strategic thing. To encourage wide industry adoption, one might adopt lgpl or a bsd-like license. Case in point: ogg.
If on the other hand the library is fairly unique or say, the competitors cost an arm and the assignment of an unborn child, then gpl's a good strategic decision. Case in point -- say, what library are you asking about anyway?
I personally default to lgpl for libraries.
I think that most of the replies in this story interpreted the question wrongly. I think the question was:
Is it legal to create application with GPL'd client, which does most of the work inside linked library with different license (f.e. completely proprietary library)?
This would allow me to use f.e. gnu readline in client while still keeping all the "interesting" stuff inside library with my own license...
I'm not a lawyer, but I think that this is the same situation as in compiling GPL'd code against Windows API - which again is something that is done quite a lot.
So what do you think?
you are correct, there is no point. i've been exploiting this for years.
I never could understand how dynamically linking my code that I wrote to someone elses code that they wrote could force me to do anything at all.
Can I make a wrapper that lets anyone in the world use your application (I bought a legal copy from you) over the Internet for free? If not, then you probably shouldn't try to wrapperize GPL libraries and use them in a proprietary application.
Because legally, I can find someplace where a click-through EULA doesn't mean squat and I'm perfectly free to run software that I own in any way that I see fit, as long as I'm not violating copyright by distributing it.
Isn't that why the Affero GPL (http://en.wikipedia.org/wiki/Affero_General_Public_License) was created ?
the "viral" nature of GPL is only the viral nature of copyright.
If your copyright system makes including a library binary into another work a derivative work of all libraries included in that work (even if it is wrapped in another library: that library itself must be derived from the components), then you cannot get past the needs of the GPL license on a library you use by wrapping it up in anything.
This isn't GPL licensing.
It's copyright.
Yes.
That is plain old copyright law.
Even if it is one function call, copyright says it is a derived work.
If you don't like that, you need to change copyright, not the license.
After all, the GPL is not the law, copyright law is the law. It is only the law that gives the GPL any validity at all.
Here is a description of the law:
http://en.wikipedia.org/wiki/Derived_work
"A derivative work pertaining to copyright law, is an expressive creation that includes major, copyright-protected elements of an original, previously created first work."
OK this means that in order for a new work to be affected by the copyright on an earlier work, the new work must actually **INCLUDE** "major copyright-protected elements of the earlier work".
So, if you statically link to a GPL library, then you include that library's code in your own work. If you dynamically link to a library, you don't include the library's code in your own work. It would seem then that the "GPL inheritance" would ONLY apply in the case of a statically linked library, according to copyright law.
Even then, there is a version of the GPL, called the LGPL, which is specifically designed to waive even that. A library licensed as LGPL allows another later work to include the library via static linking and yet **NOT** inherit the GPL requirements.
AFAIK, most open source libraries are licensed as LGPL rather than GPL for this very reason.
Other people require you to agree to a contract before looking at their program. [...] They're Dark Templars
FTFY.
When his "Freely offered" code was put into a GPL'd program he was as bad as even the WORST GPL "zealot".
Some people pick the BSD not because they like the license but that they *hate* the GPL.
Not quite right.
Now it's right.
Are you actually asking "can I circumvent the GPL on someone else's library using a wrapper"? or was the question "Why should I bother licensing my own library under the GPL, when others could circumvent it using a wrapper"?
The first of these has been pretty much answered elsewhere.
The answer to the second is to relax. If Big Evil Software Corp abuses your work this way then they're heading for a lot of bad publicity, even if you don't have (or can't afford) a legal case.
If someone gets away with this, shame on them, but what have you actually lost? Would Big Evil Software Corp have paid you (or even have heard of you) if you'd kept the code closed?
Licenses will have loopholes, and the more loopholes you try to close the more you introduce, and the more work you make for lawyers. How do you legally define the difference between a wrapper and a server so that a jury in Utah can tell the difference?
The free softwar community shouldn't fall into the trap of thinking like the RIAA and confusing "intellectual property" with real property. Violating the GPL isn't big, isn't clever but is no more "theft" than copying a movie, and the damages caused are intangible and hypothetical.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
They will need to clear this matter up if people want to see more commercial software on the Linux platform.
The GPL is a distribution license. You *can* make a wrapper that allows anyone use a GPL application for free provided you don't distribute the GPL applcation.
Likewise unless their lawyers have been careful that's probably true of a lot of commercial licenses as well. Only licenses which restrict usage affect this kid of thing.
The GPL is a grant of license based on *copyright* law. Without a copy being made it has nothing to say.
and their argument hasn't yet been thrown out.
So ask yourself: is it worth screwing around with weasel-wording interpretations of the license just to avoid paying for software?
Shutup faggots
it would be "use the copyright".
And why the pickyness? When you play your DVD, it's licensed not sold and restrictions on use go up. EULA are end USER license agreements and not a whiffle from you.
But you should read up on what "use the copyright" means since that would be the definition of "use". And if that definition is broader than you'd like, take it up with your congressman and have copyright law changed.
Are you sure the library is GPLv2 and not LGPLv2?
If a library is GPLv2 licensed, you can't do what you are talking about at all. You can't link GPL code with non GPL compatible code, library or not. You can't take a GPL library and use it in a non-GPL compatible application.
On the other hand if the library is LGPLv2 licensed, then yes, you can do exactly what you are talking about, as that is the whole point of the LGPL - to make sure that any improvement sto the library itself are shared with the community, without requiring the applications using the library to have their code opened.
Why you should use the LGPL for your next library: Because you want people to use it.
It is a misconception that you have to license an application under GPLv2 if you bind to a GPLv2 library. However is is VERY true that you fall under GPLv2 or higher if you DISTRIBUTE your code that binds to a GPLv2 library. In other words, binaries that use GPLv2 that are not publicly distributed do NOT have to follow GPL rules at all. You can ask RMS about that and he'll concur. In fact, he will tell you that localized customization of GPL software does not require redistribution or notification of changes to the "owner" (if I can use that term when talking about free software).
There is the "Lesser" LGPL license that does permit closed source (that is, short lived, unmaintainable and therefore, undesirable) software to be distributed without being free. Why undesirable?, because one day (believe it or not) that benevolent IP fascist company will go belly up.... and then ALL is effectively lost. Even SW under so-called escrow plans does NOT guarantee access since a company ultimately decides the fate of closed source software. Using closed source software ALWAYS puts you at risk since the software can actually disappear from the face of the planet. That may seem extreme, but I know I can give you several examples of VERY valuable pieces of software that have been lost due to IP closed source fascists who believed they would live forever.
So, how do you make money on GPL'd software? By supporting those that maintain software, you preserve software. When you send money to closed source companies, you don't guarantee ANYTHING. That company could kill their software product TOMORROW and there is nothing you can do about it. So, arguably, it's the wrong question to ask. The right question to ask is: Can YOU make money building your business on proprietary software that might not be there tomorrow?
If you introduce even a single bit of Affero GPL code in your enterprise, the FSF and its goons can get bailiffs to raid your data center and do an inspection of all of your code and electronic data.
Simple decency.
Oh, I forgot. There's MONEY involved. I guess simple human values are mitigated under those conditions, and you are free to revert to exploitation and predatory impulses.
"Speaking the Truth in times of universal deceit is a revolutionary act." -- George Orwell
Pardon, fumbled the link.
Why you shouldn't use the Lesser GPL for your next library
Damn, he's right... Lemme change the LICENSE file...
There... FreeBSD license good to go. Thanks for the reminder, RMS!
And what about GPLed font (namely liberation from RedHat), what if someone uses it under Windows?
Closed apps in closed environment use font, that is GPLed.
Isn't it violation of the GPL license?
Microsoft may legally prevent people from using the OS core libraries in a software project that is distributed. There is no doubt about that. But because that would be stupid beyond belief.
Homebrew applications do not link against any of the official libraries of a console, so that argument is not applicable.
Please remember that the code built into consoles functions like a kernel rather than a library. And the difference between the two is that an application never sees the kernel code. In fact, from an application perspective, the kernel features called via interrupts might actually be handled directly by specialized hardware in the processor. That is very different from a library which inherently must be software.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
Producers of proprietary, closed-source software often ask this question. How does one get around the GPL? The answer is quite simple, even obvious.
Write your own code.
That's really all there is to it. The whole idea behind the GPL, and Free/Libre software generally, is that instead of charging money for the license, the authors expect a different kind of compensation, which is that you agree to share the code and any changes you made to it with the general public. For some reason, this boggles the heck out of people who are trained to look at everything in terms of money and think it's some radical new idea, but it's actually a much older idea than money itself: the trade in kind. It'd be no different if we were farmers trading seeds.
What I find personally disturbing about the question itself is that it all but presupposes unethical intentions. You are asking how you can thwart the spirit of the license while adhering to its letter. If you're okay with behaving unethically and antisocially as long as what you're doing is technically legal, go right ahead. You can probably even ignore the legal implications of outright violating the license, depending on whose code it is -- the FSF has the resources to sue and routinely makes plausible threats to do so, but J. Random Hacker who is offering you a license to some library or other in good faith probably does not have those resources. I wouldn't personally pursue this route, but since you're looking at this in terms of what you can get away with rather than what you ought to do, I thought I'd mention it.
My personal recommendation, however, is that it would be prudent, in addition to ethical, to avoid gray areas like this. If you're producing commercial, proprietary software, the concept of paying for goods and services should not be alien to you. Consider offering money to the author of the library in exchange for a different license. It's possible that they'll say no, but then you should consider offering money to a professional programmer -- a lot of whom are short of work these days -- in exchange for writing a clone. Just a thought.
Proud member of the Weirdo-American community.
You could write the wrapper without violating the author's rights, but you'd be violating the public performance right by letting anyone use it over the Internet. Separate issue.
First of all GPL has not yet been deeply tested in a court so it is not easy to say what will happen when it is. But let's start following mental experiment:
Writing closed source application that talks to a server (like something.google.com) that runs GPL application is definitely OK.
So what if I get such GPL server and install it on my own server and let my application talk to it from any place around the globe? OK.
What if I let my customers run the server themselves and also give them my (commercial) application to connect to it? Still OK.
What if they run the server on the same computer as my own application? It is still server/client design, but no network communication happens. OK or not? Who knows.
Now why bother with two running processes? Let's keep the "server" and the application logically separated. Don't not link one to other during compile time or during runtime, but execute them both in the same process and exchange data over char[] buffer. Almost no change to the previously accepted architecture. Huge difference in the meaning of what is being done. OK or not?
Imho, unless there is a court decision, nobody will know how much one can tease GPL and still be "not guilty".
I've seen this kind of thing before, and it surprises me that so many people have such a deep misunderstanding of copyright law.
The GPL ***CAN'T*** define what a derived work is; it lacks the power to do that. Congress (not FSF and not Microsoft), through copyright law, does that.
Reading pages at FSF may clarify the issue, simply because those pages are written by presumably well-versed people (though beware: they may try to persuade you, rather than inform you).
"Believe me!" -- Donald Trump
Nothing, though some people have argued that the law's definition (*) of derived work may end up applying anyway. Of those people, you can totally ignore the people who cite the GPL's wording, as though licenses actually have power prior to someone agreeing to them. (The very idea! You agree to a license and then obey it, not the other way around.)
BTW, the neat thing about separating your program, is that if you can do that without too much trouble, then you've also just made your program multi-process. What's not to like about that? If the GPL encourages people to develop multi-process apps, all the more reason to like the GPL. ;-)
(*) This is almost a joke, though, because the law's "definition" of derived works is so incredibly vague that it's essentially not defined at all. It's almost totally up to judges' whims, and it shouldn't surprise anyone if they all contradict each other. And that puts you in a hairy position, since whoever holds the copyright of the library is going to have the power to take the initiative in a case against you, and shop for the most favorable jurisdiction in which to sue you.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The reason for the GPL is not to "protect" code or keep code free. Code will be free forever under any open source license.
The GPLv3 claims to be irrevocable, but how easily will this irrevocability stand up in court? Take the following scenario:
How can Bob's attorney convince the jury that Bob had actually obtained a copy of the work prior to the license change? Worse, how can Bob afford to hire an attorney in the first place?
See: why clisp is under gpl"
I can completely understand why you'd want to license an app under GPL. But I often don't see the point in doing so for libs. I think a lib is more likely to get play and support if it is LGPL or GPL-with-linkage-exception. For example, my company produces *very* niche test equipment (simulators). In a 1M line app, there's one place I need to do some (inverse) FFTs as part of a particular feature's initialization. FFTW would be the first thing to think of, but alas I cannot use it: GPL-only. There's a commercial license which my company cannot be bothered to pursue, since we can use an FFT I coded years ago from a math textbook, slow, but certainly fast enough for the seldom used feature esp. with CPUs so much faster than they were. How on earth does using a single math function call in an obscure feature of a 1M line app make the app a "derived work" -- only in the mind of the EFF.
I make it a point to do what I can to help the various LGPL or GPL-with-linkage-exceptions we do use. Most recently fixed a math library that was not 64-bit safe and sent the author revisions -- and that's even for a do-what-you-want non-GPL library.
The GPL is not a problem at all for companies that do not distribute software.
But has there been a legal ruling either way as to whether companies "distribute" software to their employees who work from home?
"You can't link GPL code with non GPL compatible code, library or not."
The person asking the question, as far a I can tell, did NOT ask about linking. He asked about writing one app, which would be GPL, which *would* link the library in question. Then, write another app, which is NOT GPL, which uses something like pipes, networking, or other forms of IPC (interprocess commmunications) to allow the proprietary application to 'communicate' with the GPL 'wrapper' of the application.
This would probably be legal, according to the Free Software Foundation: the GPL FAQ has a section on Plug-Ins which is probably the most responsive/similar to this question. Per the FAQ:
"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 of the plug-in makes no requirements about the main program."
Hi, here is the discussion:
http://stackoverflow.com/questions/1260591/about-mysql-gpl-and-lgpl
What do you think?
Cheers,
"I understand that if I build an application that links with a library that is licensed under GPLv2, I must also make my application GPL2"
.. provided that you also .. Accompany it with the complete .. source code
You understand incorrectly, there are provisions for linking to GPL libraries that allow for excluding your code from the section 3 provisions of the GPL.
1. Exception to Section 3 of the GNU GPL. You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.
--
3. You may copy and distribute the Program
The question is, who is the freedom for? If you want the freedom to remain with the USERS of your software, you release it under the GPL, which doesn't allow developers to take away the USERS' freedom. Sure, it's not freedom to the developer, but that's the point.
If you want freedom for the developers to do whatever they bloody well please with your code, you use a BSD license. They can take it, change it, put a padlock on it and sell it. That doesn't provide freedom for the people using the software, but it provides freedom for the developers.
I actually thought this was pretty simple...
Public performance rights only apply to audio or visual portions in general, and then only to the actual work itself. If the wrapper is sufficiently abstract, there is only a public performance of the wrapper and not the software itself. I think Mathematica has whined about people doing this sort of thing, but AFAIK the only thing preventing it is the EULA, whose strength varies by jurisdiction.
yeah but once the second library is under GPL your first library now linked against that and now would need to be GPL. This whole thing does not make sense, it's like you step on my lawn so your shoe belong to me, now your shoe step in your house so the house belong to me.
It is worth citing the key quote by RMS in that thread:
I think the same position applies to the submitter's question in this story. He is writing a piece of software that clearly shows the intention to incorporate the GPL library in question, and using a subterfuge to claim that he is not doing so.
As a few other people have said, the real question here is what counts as a derivative work, and this is a legal, not a technical question.
Are you adequate?
I wrote the LGPL v1 and badgered RMS into allowing it (John Gilmore thought up the great dynamic linking clause). RMS's biggest objection back then was exactly the case you give.
I still think in the balance the library license is a net positive for the FSF's cause. But this hinges on the definition of a "derivative work"
Wrong. MySQL claimed that if you used the GPLed MySQL client libraries then your application would be a derivative work. They never claimed that any application accessing a MySQL database would be GPL, only ones that used their GPL client libraries.
Yeah, I was thinking more about things like adventure games, where the public performance right is clearly implicated. It's hard to invoke with an engine like Mathematica, which provides factual results only.
Indeed. Somebody's failing to distinguish between two things:
The terms of the GPL say that derived works must be licensed under the GPL. The FSF takes the position that a program that links to a GPL-licensed library is a derived work of that library. This doesn't preclude them from taking the position that, say, an application that calls a GPL-licensed service through SOAP isn't a derived work of the SOAP service. (In practice, I'd expect them to take positions that depend on the details of the application and the SOAP service.)
Are you adequate?
This is, at the very least, not the position that the FSF takes. And I agree with them.
It comes down to how you interpret the part that says "major copyright-protected elements of the earlier work." You're reading "elements" as actual pieces of code. Copyright law in general, IMO, doesn't read the term "elements" as narrowly as you're doing. For example, the elements of a novel isn't just the words and their arrangement; it also includes the characters and the plot. You can't publish your own Harry Potter novels commercially without permission because the character and tons of background plot elements are protected by copyright. That your novel shares no substantial amount of text with the originals doesn't come into the argument.
So for example, the FSF can take the position that the call interface of a GPL-licensed library is a major copyright-protected element of the library itself, and that by using the library in your application, you're incorporating that element of the library into your work. Or more generally, if your application was written to use the GPL-licensed library, and cannot work unless linked with that library, then your application incorporates the functionality of that GPL-licensed library, and that therefore to distribute it, you must license it under the terms of the GPL.
Are you adequate?
Regardless of what zealots would like you to think, there are limits as to how far GPL's effect can go and no one is going to challenge them.
If the wrapper is network based for instance, i.e. you create a wrapper (also GPL'd) which wraps readline into a network service so that another app that isn't GPL can communicate with readline via sockets ito another process, GPL can not and will never be applied to your library connecting to it.
No one will ever seriously contest this, as doing so means every chunk of software involved in the Internet would all have to abide by every license involved which is impossible anywhere except some fantasyland that Stallman and his cult live in.
So yes, there are ways to wrap GPL apps/libraries and get around the requirement to GPL the other code. The advantage you have with GPL is that they can't revoke your license because they don't like you, or rather, the disadvantage to authors of GPL code.
Microsoft can revoke your license pretty quickly or at least no grant you any new ones if they don't like how you've worked around their rules.
I hadn't really thought about working around GPL this way until you mentioned it, never really had it become a problem for myself. As a general rule if theres any serious library that you would want to link against that is GPL, there is another actually free BSD/MIT/Apache style library that matchs it well enough so you don't have to use the GPL version. I've yet to run into any instance of a library of any importance or side that was GPL only and didn't have a free/open source counterpart. And yes, I'm saying GPL isn't actually free or OS, if that bothers you then flame away cause it won't bother me.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Adopting a body of code is like adopting a child. Its terms change your terms because you _chose_ to _adopt_ it.
The thing people really don't get is that you have _no_ _right_ _whatsovever_ to the code in *any* library outside the terms of copyright law.
The GPL is a grant of license (not a contract) and it is(presumably, in your question) the sole means of receiving that license to use that code. As part of that license you get an unlimited license to use the code yourself for any private purpose, and you get the much-more-limited license to redistributed the code to others IF AND ONLY IF you agree that you will distribute all the source code for the whole shebang you distribute under the GPL, where that code is "linked with" or otherwise joined to the piece(s) you received via the GPL.
When you decide to use that GPL code you decide to adopt the GPL for the existing code you intend to link with that code for any _distribution_ of the combined result, if you don't so decide, then you may not use the GPL code in that distribution. There is no third option.
In the finer points:
The code _you_ already wrote does not become _solely_ GPLed; its source must accompany the distribution with the GPLd code, but it doesn't have to accompany other distributions under other licenses. So if you make two products X and Y out of largely the same code base, but you have the GPL readline library linked with Y, then you must include the entire source base when you distribute Y, but you can still withhold the source base for distributions of X. Further you cannot give someone X and Y and then put a term on the distribution of X that prevents them from using the source code they got with Y. Further still if I get X from you, and my buddy gets Y from you, my buddy can give me the source code from Y and no term of license for X can prevent me from using that code. Even if X had such a term, you would be civilly liable for going after me for using the source from my buddy because your attempt to use X to limit my use of Y means that you were violating copyright law by giving out copies of Y, since you may not add restrictive terms to the GPL. I have a license for X, I get a license for Y from my buddy when he gives it to me, and that license power flows from you (though him to me) unimpeded otherwise it cannot flow from you to him and you are the bad guy.
The larger question of "why would anybody agree to that?" is easily answered.
It's a financially stable cost/benefit transaction. You agree to "pay" for the source code you receive and pass on, by adding to its mass by including your code under the same terms.
From a business stand point it is a nearly perfect deal. you "pay" on the back end, when you distribute, and all you "pay" is the cost of disclosure.
Compare this to a license for Microsoft Wince (I didn't name it 8-) which you have to pay for up front to the tune of hundreds of thousands of dollars, and then pay for it on the back end again with a per-unit-sold fee.
Some people resist the GPL because they beleive that the "value of their IP" in sweat equity is larger than it actually is. This is a delusion that comes from the outrageousness that is the music industry where one months work is supposed to keep paying dividends forever (e.g. how long did anybody work on the Beatles song "Help"? Should it still be paying dividends to anybody? honestly? I wish I could get re-paid every time someone uses my software, but _real_ life aint even supposed to be like that. 8-)
So anyway, for the cost of a $0.38 CD tossed into the wrapper with your product, or a web site that you promise to keep up for seven years, or whatever, you can leverage ungodly amounts of code.
The "but someone will steal my precious" arguments are exactly that crazy. Your precious isn't that precious, and most people would rather pay you for the next version than write that version themselves. The GPL startup cost cannot be beat.
_BUT_ if you adopt the GPL later in the development cycle, yo
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
The right question to ask is: Can YOU make money building your business on proprietary software that might not be there tomorrow?
Yes.
...And people have been doing it for 30 years and still are with 30-year-old software.
The burden of keeping the software running falls on the IT departments, but with the exception of hardware-bound eccentric UNIX flavored software, that's not much of an onus.
Our department uses (extremely domain-specific) MS-DOS accounting software from 1983 running under Dosbox. I recompiled Dosbox with a tweaked version of the Windows SDL library so that it didn't require that annoying stdout window which SDL apps seem to require by default and confuses the hell out of the secretary, set up a dosbox.conf for the program, and created a shortcut which launches the program by autoexec. Now this 26 year old software runs in a window that looks no different than the terminal window she's used to using to connect to our campus mainframes - which themselves are running an ancient version of IBM-made UNIX.
I don't see how that makes it difficult to make money, and the cost for this software was written off 20+ years ago - hardly a bad investment. We've talked to the company that made this software perhaps 6 times in those 20+ years, and each time was to resolve some minor irritation that could have been fixed with some amount of effort on our part, but we paid for support because it was cheaper. If the company had gone tits up a decade ago, we'd have lost perhaps a hundred and fifty dollars worth of time reentering some information to start over instead of paying seventy-five dollars for support. Not that significant a loss.
The certainty that the moment a company goes out of business, all of their closed-source software stops working is ludicrous. Even should the dongle for some antique software stop working, the DMCA (in the US) specifically provides for circumventing that copy protection should the company be unable to provide a working replacement. Other countries have even less draconian laws governing reverse engineering of software. That's not to say that it wouldn't be much easier (and cheaper) to use a piece of software that doesn't have copy protection and provides its source, but to delude yourself into believing that it's impossible to make money with outdated closed-source software is to ignore the fact that the vast majority of the business and governmental world is already doing it.
The land shall stone them with the bread of his son.
That would be my choice too. The LGPL is all sorts of fun. LGPLv3 is incompatible with GPLv2, so any project that included GPLv2-only contributions is royally screwed when an LGPL'd library that it depends on switches from LGPLv2.1 to v3. It's left with the need to either rewrite the GPLv2 bits or fork the library. Poppler is a good example of this; it's based on xpdf, which is GPLv2-only and is currently about the only half-decent open source PDF library (there's also a nice BSDL Java one, but it's not really usable by non-Java code). Any programs that incorporate PDF viewing capability via Poppler can't use LGPLv3 libraries.
I am TheRaven on Soylent News
No, the first library does not link against the second. The second links against the first. Essentially the second library is an extension or plug-in. The first library works in it's entirety without the second.