- foo.py is a Python library released under the GPLv3. bar.py is a library distributed commercially. If bar contains import foo, must bar.py be released under the GPL?
- Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function?
- Does the answer change if foo.py does not ship with bar.py and does not require its presence to function?
- libfoo.so is a C shared library released under the GPLv3. bar.rb is a Ruby library that uses Ruby/DL to call into libfoo (via dlopen() and friends). Must bar.rb be released under the GPL?
- Does the above answer change depending on whether bar.rb is distributed with libfoo.so?
- foo.js is a JavaScript library released under the GPLv3. bar.js is a library with all rights reserved. For performance reasons, I would like to minimize all my site’s JavaScript into a single compressed file called foobar.js. If I distribute this file, must I also distribute bar.js under the GPL?
- foo.js is a JavaScript library released under the GPLv3. Bar.app is an application developed on the Mozilla platform using XUL. If Bar.app includes foo.js (via a <script> tag), must the source to Bar.app be released under the GPL?
- Foo.exe is an application released under the GPLv3. Initech’s HR department modifies Foo.exe for use internally. If Initech shares this application with the Accounts Receivable department, does that count as “conveyance” and require release of the modifications under the GPL?
- IniSys is a fully-owned subsidiary of Initech. If Initech shares its modified version of Foo.exe with IniSys, does that trigger the GPL’s conveyance clause?
- IniCom is a majority-owned subsidiary of Initech. If Initech shares Foo.exe with IniCom, does that trigger the GPL’s conveyance clause?
- Do either of the above answers change if IniSys or IniCom pay IniTech for the right to use (the modified version of) Foo.exe?
- Jane is a consultant hired by Initech. If Jane wishes to purchase Foo.exe from Initech for use in her consultancy, does that act trigger the GPL’s conveyance clause?
- Jane is a consultant hired by Initech. If Initech provides Foo.exe to Jane for code review, does that trigger the GPL’s conveyance clause? Does the mechanism that Initech uses to provide Jane the code change the answer?
- As a standard practice, Initech requires that all consultants working with them use the modified version of Foo.exe. Does this trigger the GPL’s conveyance clause?
- To apply for a job at Initech, potential employees must visit an Initech recruitment center and complete an job application using Foo.exe. They do this on computers provided by Initech. Does this trigger the GPL’s conveyance clause?
- Initech now decides to make Foo.exe available to job applicants who wish to use their own computers, provided they visit a recruitment center and are within Initech’s private network to download Foo.exe. Does this trigger the GPL’s conveyance clause?
- Initech now decides that any job applicant may download Foo.exe from any network connection via a VPN connection to Initech’s internal private network. Does this trigger the GPL’s conveyance clause?
- Initech finally decides to simply let any applicant download Foo.exe from a public web server. Does this trigger the GPL’s conveyance clause?
- This publically-available download of Foo.exe requires a password only available by calling Initech HR. Does this form count as conveyance?
- The previous six questions are all variations on a theme. Is there a basic principle than enables them (and the other countless variations) to be answered quickly by laypeople?
Bonus question:
- I am a long-time open source user, producer, and advocate; my business revolves around open source consulting. My clients typically ask questions similar to the above. Is there a mechanism I can use to easily advise my clients in these matters, or must I retain a copyright attorney with GPL expertise?
Comments:
I had a similar experience to the above questions with the pyvcs library Justin Lilly and I recently released. Both the Mercruial and Git backends use GPL'd libraries. Being the responsible person I'm not I contacted a real lawyer (after trying to figure it out myself an realizing my opinion of the GPL didn't really matter). Open source programmers have an awesome resource available to them in the Software Freedom Law Center. Unfortunately the only answer they were able to give me to the question "Does a Python import on a GPL library invoke the GPL?" was "maybe", as there is zero legal precedent or case law for it. Unfortunately fairly basic, but unresolved questions like these constitute a massive problem with the GPL. The point of a legal document is to have concrete rules to follow, with the number of ambiguities and uncertainties surrounding it the question of whether it protects software freedom is totally unanswered. Ignoring any philosophical differences I have with the GPL (of which there are several), using it in an environment that has anything beyond basic static linking is a fundamentally bad idea because of the sheer number of legal ambiguities surrounding it.
I don't know the answer to the questions about Python imports, and it doesn't seem that anyone does (no-one really will until it's tested in court, I guess). But I _think_ the questions about "conveyance" might involve a misunderstanding of what the GPL actually requires (though it's equally possible I misunderstand). The GPL only requires that you make the source available to the same people that you distribute the software to. It only requires public "release" under the GPL if you're distributing the software to the general public. So my answer to question 8, for instance, would be "Initech is required to make the source of foo.exe available to the Accounts Receivable department under the terms of the GPL. They aren't required to make it available to anyone else."
But, of course, I could be wrong.
On #8. You _never_ have to give anything to anyone. The GPL dictates the rules _when_ you give or sell the code. I assume both departments are owned by the same company, but even if they weren't, you only have to give it to the other department under the terms of the GPL, you are never forced to give code to people with whom you have no relationship with.
Great list of question. I am a noob when it comes to legal talk. It would be great if you would turn this into an FAQ once you get answers to these questions.
Also nice: foo is an application server released under the GPL using a GPL library that exposes the library's functionality over HTTP/DBUS/COM/whatever. Does the application that interacts with this interface have to be GPL as well?
Carl: if I'm reading the GPL correctly, it requires that software "conveyed" to "the public" be released in source form also to "the public." My questions are less about the "conveying" and more about who counts as "the public."
After reading the rest of the questions it seems you are trying to find ways to get around the GPL? The point of the GPL is that if you sell or give GPL code, you cannot deny the rights that you enjoy to the receiver. People didn't voluntarily right code so you could get rich and not share your improvements. They wrote it to share. This is the spirit of the GPL and this is what the foundation would attempt to enforce. Letting people see the code, and not giving them the code wouldn't be against the spirit of the GPL. I wouldn't worry about such things. It's meant for people who will actually use the code, because they want to. And that they will actually use it on their own computer. If you are trying to figure out a way to distribute proprietary code built on GPL code, then you are in violation of the spirit of the GPL
Some discussion of the contrasts with LGPL would be nice. Here are two interesting reads by Lawrence Rosen (http://www.rosenlaw.com/) : http://www.rosenlaw.com/htm... "The Unreasonable Fear of Infection" and http://www.rosenlaw.com/Ros... "Reciprocity and the GPL"
Jacob: Why do you have to define who "the public" is? It seems pretty simple: anyone who is able to get the program from you needs to be able to get the source, too. So if you make the program available on a public webserver, then you have to make the code available too, to anyone who can access that server. If the program is on a private internal server, put the code on that server too. If you send the program by email, send the code by email to the same person/people. Where's the difficulty? Where's the need for a definition of "the public"?
Bob: frankly I'm offended that you think this is me "trying to find ways to get around the GPL." I would have thought that my open source bona fides are well established, but apparently not.
There are many, many reasons why a party may wish to distribute code under some license that is not the GPL. If you accept that these desires are valid, then you have to establish what the rules are regarding combining this code with GPL-licensed code. And unfortunately despite my extensive research into the topic, there are many situations in which I simply can't answer one way or another.
Now, if you happen to be a GPL purist and believe that the only Real Free Software is GPL-licensed, or that all software ought to be Free, then it is true that these questions don't need to be answered. In my world, however, they're a big deal.
Carl: so, according to your understanding of the GPLv3, if I sell you a piece of modified GPL software, I must only make that software available to you?
If that's the case, then why must Amazon make the source code to the Kindle available publicly instead of simply shipping the source code on the device?
James, Bob: I think Jacob has made it clear that supporting Open Source (or free software if you prefer) and answering these questions are not in the least bit orthogonal. But I am forced again to bring up the example of pyvcs. If the Python import mechanism triggered the GPL then I would be required to license django-vcs as GPL, and then I'd be required to license piano-man under the GPL. Why is this bad you ask, after all, this just means that more software is free right? Unfortunately it also means that I couldn't use piano-man (or any of its underpinnings where I work) because we have some internal code we want to work alongside it, and that would obligate us to GPL our code, which we don't want to do. We don't mind releasing our stuff as open source, indeed we open sourced some of it already and my first task here was to reorganize our branches to make it easier to open source. So, I think the assertion that not wanting ones code GPL'd means your trying to deny people credit, or are just out to get rich is entirely baseless. Further, I think that type of language points to a more fundamental philosophical question of whether freedom means doing and saying things that I agree with, or is the right to do something that I wouldn't like just as important?
Jacob: Yep, I believe that's right. Section 5c is the core: "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy." Seems pretty clear. I don't think Amazon _has_ to put the source code on a public webserver, they could put it on the Kindle, because that would fulfill "anyone who comes into possession of a copy". It's easier for them to put it on a public webserver in this case, and they don't lose anything by doing so. But if you're only distributing something privately, you only have to license the source within that same private circle.
In fact, if you read further, it's even allowable in some cases to accompany the "object code" with nothing more than a written promise to provide the source on request (which, of course, you're then obligated to honor).
It does seem that if you only _intend_ to distribute the Program privately, but somehow it leaks, you are still required to provide the source to anyone who gets a copy of the Program. So I think you do lose the right to prevent someone who gets ahold of the code (in a way you didn't intend) from going ahead and using it under the GPL.
Bob: It seems to me that Jacob's questions here reflect a desire to understand and abide by the GPL, not to "get around it".
Carl: wait, let me make sure I get this:
I create a derivative work of GPLv3-licensed software, but retain it for use internally (thus not requiring public distribution of my derivative work). A disgruntled employee steals the binary and leaks it. I now need to provide the source code to anyone who comes into possession of that leaked binary? Really?
In my understanding #1 is a clear yes. I read some time ago, that including or linking a GPL library forces the including program to be released under GPL. A way to work around this is writing a (GPL'ed) wrapper that provides - for example - a TCP interface you can use with your commercially licensed app.
Jacob: It's well known that you can't steal software, you can only copyright infringe it :P
Bob: What Jacob really wants to ask here is, "can I use GPL libraries alongside my non-GPL python code?". (At least, that's what I want to know).
If the answer to that is "No", then my reaction would be to just not use GPL stuff, and look for another alternative or write my own.
It gets even worse with what Alex is trying to release. He is creating a tool to interface with a GPL tool - if not anything, it will foster adoption of the GPL tool (mercurial). However, due to GPL restriction, he may not be able to release it at all. *This* is the annoying bit.
Jacob: IANAL, but that does seem to me to be the case. You are required to license the software under the GPL to that employee if its derived from another GPL work, and thus s/he has the same rights under the GPL that you do to distribute it to anyone else in the world. "Keeping it private" is something you are fully entitled to do yourself, but it is not a choice you can enforce on anyone else you share it with.
Jacob: To clarify, in that hypothetical you are not required to share the source with "anyone in the world", I don't believe. It's your disgruntled employee who bears that responsibility. You'd only be required to share the source with your employee.
Though it seems that's less clear in GPLv3 than it was with v2, so I could be wrong in the case of v3. Seems a bit problematic if anyone can distribute software you wrote and thus impose responsibilities on you (that could come along with very real bandwidth costs etc.)
Carl, Jacob: I'm weighing in here as a relative noob, but... if you make software available internally and provide the source code, and someone leaks the binary (i.e. makes the binary available to the public without the source code), *you* are not the distributor -- the person who leaked the software is the distributor.
Wouldn't the person distributing the software to the public (i.e. leaking it) be the one required to also provide the source? That seems obvious to me... but, obviously, I could be wrong.
GPLv3 has 674 lines of legal code. To understand that amount of code you need a professional. Furthermore, this is legal-code and a human judge will end up 'running' the code with unpredictable results.
I would choose some reasonable answers that work for me and pay a lawyer to wrap it in legal double-talk so the client feels better but still can't hold me liable. It's probably going to be expensive, but I don't think you can avoid it, freelancing for enterprises. They all need a way to cover their asses and that's what lawyers are for.
re:Amazon, they could simply ship the source code on the device, but it's simpler for them to post it on the web site.
Note that while the GPL (even v2) only requires you to offer the source code to whoever got the binary from you, you cannot attach any other strings; anyone you give the source code to may put it on the internet for anyone to download. Amazon knew source code WOULD become available on the internet whichever way they gave it, and legally so, so they saved some space/CD on the kindle package and put it on the internet for anyone to download.
If you sell a GPL-bound binary for $1M, and provide the source, it will be unlikely that your customer would go and upload the source code to sourceforge, but the GPL allows them to. It does not require YOU to do that.
You should email licensing@fsf.org with these questions, and post the response that you get. This email address is provided for exactly this purpose.
Jacob: This might be helpful. http://www.gnu.org/licenses...
The issue of illicitly released code came up when Nullsoft published Waste a few years ago and AOL took it down because they had no right to release the code or choose a license for it: http://slashdot.org/comment...
Noah: Unfortunately all the FSF can provide on a number of these questions is their opinion on the matter. Having spoken with the Software Freedom Law Center about the import issue recently the reality is there is no answer to some of these questions because no one has ever taken them to court.
The answer to almost all of these: "It Depends". It depends on who is interpreting all these various permutations of all these possible interactions. The main question is "Whose interpretation of the GPL am I beholden to?" One imagines it's that of the various copyright holders, but of course you have no way to know beforehand what it is. And thus are lawyers enriched.
Practically speaking, there are very few *libraries* distributed solely under the GPL as opposed to the LGPL for precisely these reasons.
In all cases it depends on intent. If your intent is to circumvent the purpose of GPL3 (make sure that everything that uses it is GPL3 as well, thereby ensuring that downstream users have the same freedoms that you are leveraging to make your software) then in each case the answer is YES you must GPL3 your software, otherwise you're just trying to commit copyright infringement.
Remember a judge can view your actions as an attempt to circumvent the license.
Here's my advice: Don't mix licenses. Anything that uses GPL3 code should be considered GPL3. Expect that the code will be distributed. If you don't want the code distributed, don't use GPL3 code. It is only way to be safe. We're not lawyers so keep it simple.
Regarding the "theft of code" option, the FSF actually provides relatively clear guidance on that: http://www.fsf.org/licensin...
In brief, illicit releases don't count.
To speculate on internal distribution, my understanding of the license is that a single organization can keep internal modifications internal, and then by policy, prevent others from making a release "for them." I believe that's covered in section 2.
I understand its a legal thing and scary, but not many ppl have been sued. If you are truly honoring the spirit of gpl, then I wouldn't worry. The entire legal crap is only there to protrct the spirit. I'm not a purest and have no problem with bsd. I do respect the wishes of the author though, and if they set the rules as gpl, abide or use something else. I hate to see so many mistruths spewed about. You only have to give source to those who legaly obtained a copy from you. And the reciever enjoys all the same rights as you. That is the requirement. If you try to find ways around the wishes of the author it stinks. If you feel your goals are in line with the authors but against the gpl, you can request a special licence.
@Alex Gaynor: The ambiguities about what constitutes a derivative work are really issues with copyright law. It is pretty uncharted and, to the court, very technical territory.
1. foo.py is a Python library released under the GPLv3. bar.py is a library distributed commercially. If bar contains import foo, must bar.py be released under the GPL?
bar.py be released under the GPL. You used GPL3 code.
2. Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function?
Does foo.py need or use bar.py to run?
YES - foo.py needs to be GPL3
NO - Why did you import it?
3. Does the answer change if foo.py does not ship with bar.py and does not require its presence to function?
If it can optionally use it then the whole thing needs to be GPL3 compatible.
If it is optional it means it uses it.
4. libfoo.so is a C shared library released under the GPLv3. bar.rb is a Ruby library that uses Ruby/DL to call into libfoo (via dlopen() and friends). Must bar.rb be released under the GPL?
Assuming you are distributing bar.rb, yes bar.rb should be GPL
5. Does the above answer change depending on whether bar.rb is distributed with libfoo.so?
Are there multiple libfoo.so? Does the software work without it? There's a tonne of context here.
The answer is if it was designed/intended for libfoo.so then it must GPL3
6. foo.js is a JavaScript library released under the GPLv3. bar.js is a library with all rights reserved. For performance reasons, I would like to minimize all my site’s JavaScript into a single compressed file called foobar.js. If I distribute this file, must I also distribute bar.js under the GPL?
Don't mix licenses. Read the preamble. All the JS on the page was supposed to be GPL3 compliant.
Things which serve or crap out GPL source code probably don't have to be GPL'd.
7. foo.js is a JavaScript library released under the GPLv3. Bar.app is an application developed on the Mozilla platform using XUL. If Bar.app includes foo.js (via a <script> tag), must the source to Bar.app be released under the GPL?
I don't understand. Do they share the same interpreter/process? Will Bar.app execute foo.js?
Pretty sure Bar.app needs to be GPL. If Bar.app was a webserver that'd be different.
8. Foo.exe is an application released under the GPLv3. Initech’s HR department modifies Foo.exe for use internally. If Initech shares this application with the Accounts Receivable department, does that count as “conveyance” and require release of the modifications under the GPL?
Depends on your company's policies and ownership rules. Probably not. Again, context. The law isn't fun.
9. IniSys is a fully-owned subsidiary of Initech. If Initech shares its modified version of Foo.exe with IniSys, does that trigger the GPL’s conveyance clause?
Well it depends on ownership doesn't it?
To “convey” a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through a
computer network, with no transfer of a copy, is not conveying. To “propagate”
a work means to do anything with it that, without permission, would make you
directly or secondarily liable for infringement under applicable copyright law,
except executing it on a computer or modifying a private copy. Propagation
includes copying, distribution (with or without modification), making available
to the public, and in some countries other activities as well.
To be safe, just assume it is GPL3'd the whole way.
10. IniCom is a majority-owned subsidiary of Initech. If Initech shares Foo.exe with IniCom, does that trigger the GPL’s conveyance clause?
Most likely.
11. Do either of the above answers change if IniSys or IniCom pay IniTech for the right to use (the modified version of) Foo.exe?
Depends on the copyrights in the software, did they own 100% of the software?
12. Jane is a consultant hired by Initech. If Jane wishes to purchase Foo.exe from Initech for use in her consultancy, does that act trigger the GPL’s conveyance clause?
Depends on the copyrights in the software, did they own 100% of the software?
13. Jane is a consultant hired by Initech. If Initech provides Foo.exe to Jane for code review, does that trigger the GPL’s conveyance clause? Does the mechanism that Initech uses to provide Jane the code change the answer?
Depends what machines she uses. Her own? CONTEXT.
14. As a standard practice, Initech requires that all consultants working with them use the modified version of Foo.exe. Does this trigger the GPL’s conveyance clause?
Who owns Foo.exe, are the consultants using their own machines? CONTEXT.
15. To apply for a job at Initech, potential employees must visit an Initech recruitment center and complete an job application using Foo.exe. They do this on computers provided by Initech. Does this trigger the GPL’s conveyance clause?
no
16. Initech now decides to make Foo.exe available to job applicants who wish to use their own computers, provided they visit a recruitment center and are within Initech’s private network to download Foo.exe. Does this trigger the GPL’s conveyance clause?
yes
17. Initech now decides that any job applicant may download Foo.exe from any network connection via a VPN connection to Initech’s internal private network. Does this trigger the GPL’s conveyance clause?
yes
18. Initech finally decides to simply let any applicant download Foo.exe from a public web server. Does this trigger the GPL’s conveyance clause?
yes
19. This publically-available download of Foo.exe requires a password only available by calling Initech HR. Does this form count as conveyance?
yes
20. The previous six questions are all variations on a theme. Is there a basic principle than enables them (and the other countless variations) to be answered quickly by laypeople?
Is the software executing on Initec's computers or not? Does the software leave Initec controlled property (computers/networks). If it executes on anything not owned by Initec then the owner of that machine or that user using that software has full GPL rights to it, UNLESS they are an initec employee.
Hardly any of these questions are answerable without a lot of discussion and context. You'll find it very frustrating. I am not a laywer, this was just my stab at it.
It is best to interpret the GPL as follows: you may use GPL'd software if you agree to all terms of the GPL for all software that uses that GPL'd software.
An easy way to explain the GPL is the "bugfix criteria". If GPL code is used anywhere in a piece of software, then anyone using that software must have to right to fix bugs they find in it, or otherwise improve it. If you're withholding a part of the code that would prevent them from doing so, you're in violation (at least in spirit).
Really, all the freedoms of the GPL come from this idea, even the right to distribute copies. Imagine if you could fix bugs, but not give a copy of the improved version to anyone else.
People call the GPL viral but I think that's wrong and misleading. I say it's "all or nothing". You can't make your software "kind of" free.
I would recommend tracking down the authors of the various libraries you plan to "link" (for want of a better term, as it's now clobbered in very pooly defined supposedly legally binding terminology). Ask for permission in writing to do what you want to do. I think most OSS authors are amenable to allowances for specific cases, if politely approached. As far as I know, this is the only way to gain any kind of tangible legal assurance.
This leaves the case of highly collaborated projects, where, despite a common license, there is uncommon copyright. In these cases, the common understanding is that source code brought into a project is brought in under the same license, or explicitly licensed. The same is not so common with copyright, and projects should be encouraged to firm up these policies. My policy for patch authors is simple, what comes into the project, is owned by the project, and the copyright comes too. That being said, this is only something I tell people when I merge; I too am guilty of not formalising these ideas - but it's such cruft - I want a better solution. Credit will be given appropriately, but credit is not copyright. Of course, I'm also a fan of the MIT license for one particular portion of the license: "or substantial portions of the Software". To me, this distinction suggests that people can copy and paste or regurgitate portions of my code in their programs, should they find it useful. I consider my code of worth, and so I consider my users ability to do that freely a good thing. Public or private, I'd prefer their software had my code, than most of the stuff I stumble upon. I also feel it's safer to *read* MIT licensed code.
So here's another question for your list:
"If I read GPLv3 code, and one day write the same code, to solve a similar problem, because the pattern is a good fit, and the structure I remember, but not the source, am I liable for GPL violation?"
Whilst this might sound far fetched, it raises some interesting questions with regard to programming patterns. In ruby code for example, there will be plenty of repetition of certain code blocks, like File.dirname(__FILE__). Whilst this may be a very small amount of code, one must ask, how much code may be extracted before it is considered "a copy"? What metric can we use? In a very well documented program in a high level language, some 80+% of the "code" can be removed without altering the behaviour of the runtime at all.
As far as tackling the issues in highly collaborated projects, generally the project lead, or original author *should* do, but I wouldn't put my professional stamp on it from a legal standpoint. If it was a client, I would explain my understanding, and recommend that this is probably enough, given the lack of case law.
Long comment, I think that's more than enough...
Good questions. And you haven't even touched the issue of patents, which in my opinion is the biggest problem with the GPL licenses. Very few people read section 7 of the GPL and understand the implications, except for company lawyers -- which is why you see large companies shying away from the GPL. It's not because of the source publishing requirements -- it's because of the anti-patent clauses in both the GPL and LGPL.
I guess you published these questions because you were unable to find answers anywhere. I tried asking the FSF a number of times -- but the difficult questions were always ignored.
"Things which serve or crap out GPL source code probably don't have to be GPL'd."
This is interesting from the point of view of high level interpreted languages. If you don't have to GPL javascript source when it's running alongside GPL code, then why should this be any different for code that is not ever "compiled". The object code in question exists only at the customer site, and only for the life time of the application.
In a high level language, if you're "linking" against a .so, say using libffi, are you "linking", or are you using FFI?
You're using FFI, libffi is "linking". Does this mean libffi could be the first target for GPL linking violations en-mass? (sorry folks, I do hope not).
There are success stories where people have been allowed (by original authors) to extract code from GPL bases and use them elsewhere. An example from the top of my head is evident in the bottom right of this page: http://rubyhitsquad.com/Vla...
The fact that you only have to share the code with people you distribute the code to doesn't really change anything. Those people are now licensed to redistribute the code however they like. So sharing the code with one person is equivalent to sharing it with the public. You're unable to make any sort of private agreement with a third party because that would violate the GPL.
So suppose it's an internal tool. Does every employee who uses the code need to have access to the source? If so, those employees could turn around and release it to the world, and there's nothing the employer could do about it.
The upshot is that the GPL is, more or less, incompatible with any other licensing option. That stinks.
@AlexGaynor: "Unfortunately it also means that I couldn't use piano-man (or any of its underpinnings where I work) because we have some internal code we want to work alongside it, and that would obligate us to GPL our code, which we don't want to do."
That's a reasonable worry - but not actually an issue, for two reasons.
1) if it's your copyright, you can do whatever you like with it. The rest of the world can have it under a GPL license, but you can do whatever you want with it.
2) you can dual-license things; release them under a GPL-or-other-at-choice-of-licensee license, then it can be included in GPL'd projects, and under whatever terms users like, elsewhere. See for example the license for Ruby: http://www.ruby-lang.org/en...
For me it is easy - i avoid GPL3 and stick with GPL2 or other licenses.
This is a major reason that I lately have begun to argue that the best licensing policy is Public Domain.
bob: If the author releases code subject to the GPL then one must assume, barring evidence to the contrary (e.g. granting of some alternate license) that the author wishes the terms of the GPL to be enforceable. The spirit of the GPL is embodied in the terms of the license and one can only truly honor the spirit by fully abiding by the terms of the license - this is why it is necessary to understand exactly what these terms mean. It is not fear, it is essential to honoring the license and avoiding use of such code where the terms are unacceptable.
Naw. I totally disagree. The only reason gpl is the way it is is because people try to finf loopholes. Someone could theoretically abuse it, but its never happened. History tells us that the only penalty is to stop using gpl code when you violate, no big deal. If companies are scared of something that could theoretically happen but never will, I would suggest insurance. Also, employees are not included, so there is now worry. Its really just for ppl distributing code. In my consulting experience, most clients can be made to understand the value of cooperation. After all, most businesses aren't competing based on their software. Even cooperating with a rival is ok when put in this light. Anyway, do you have clients that sell prop code that uses gpl? If they are worried about internal stuff or accidently distributing then they shouldn't worry. Spirit of the license is very important to a judge. The spirit of the gpl is to protect the 4 freedoms as outlined very clearly. Also, most devs will give a diff license if you ask. Sorry so disjointed, and for insulting you earlier. But it does seem that your clients don't understand the point of the gpl and are trying to defeat it. Whether you agree with it or not, a little education goes a long way. I'm on blackberry so this is a mess.
I think Morty Yidel overlooks an important issue in 2 & 3
In these cases you aren't distributing the GPLed software. Thus you are unconstrained by the terms of the GPL unless your code is a derivative work.
That's a tough question, does merely using the API provided by a GPLed library make your software a derived work? I dunno. If yes I suspect O'Reilly may have some issues since it's hard to see how written descriptions of the API would not be derived works as well.
Morty has some answers, which I generally agree with.
I differ in opinion some from him for question 3. Though now that I think about it, I differ in part because Linux has gone under the assumption that optional use, enabled by a user, does not imply the GPL. OTOH, I think this was a point of contention with updating from v2 to v3. But I'm not sure, there were other points of contention that have little to do with any of these questions.
There are ways of optionally including code that definitely do not invoke the GPL on the calling code. For instance, modifying the proprietary code on your own computer to use the GPL library. You are definitely allowed to do that. You are allowed to create a plugin compatible with the proprietary software that uses GPL code. If some third party creates such a plugin and distributes it, that certainly can't influence the license of the proprietary software, and I don't think the GPL can keep the third party from writing and distribution such a plugin. It's just tricky when it's the *same* party writing the plugin and the code. And in a primitive sort of way "try:import X; except importError: pass" is a plugin system of sorts. The line is fuzzy, and I use intention to clarify the issue, not arbitrary definitions around software itself.
Are you trying to get around the GPL in a dishonest way? That's not cool. Illegal? I don't know (no one knows, there's no precedence), but I think "not cool" is good enough reason not to do something, so I don't feel like it needs to be explored too much.
Unlike Morty I don't think 6 necessarily requires you to GPL all the code. The page is one runtime, but I don't think runtimes have to have a single license.
And I don't think compression means anything. Putting it in one tar file doesn't mean anything either. You are however required to link to the uncompressed GPL library in your source.
7 - if Bar.app requires the GPL library foo.js, and was intended to use it, then the GPL applies. It doesn't matter how you are including it. If it does not require it, then the GPL does not apply. Running GPL code in a proprietary runtime is fine. Otherwise Windows GPLed programs would be illegal!
8 - no, it's just one entity. I know companies can have divisions buy things from each other, but that's just internal accounting and politics, they can duke it out themselves however they want. It's not like AR is going to sue HR.
9 - I'm not sure, since a subsidiary does have distinct legal entities, but I'd say it's the same as 8 in a practical sense. It's internal politics.
10 - yes, they are two distinct entities.
11 - I don't think payment changes anything in the GPL.
continued:
12-14 - I believe under her contract she's working as part of the entity that is Initech, so it's private use. I don't believe the ownership of the computer makes a big difference, as while she's under hire she is "part" of Initech. Just like uploading code to EC2 doesn't mean you've somehow transfered the software to Amazon, even though the physical computer belongs to them. So for her to use the software on her computer while under hire is fine and is not conveyance. It's her obligation to delete or not use that software while not under hire, and it doesn't effect Initech's claim on the software.
Peter Gerdes, read about corresponding source in http://www.gnu.org/licenses....
Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
Also see: http://www.gnu.org/licenses...
@Morty Yidel:
" 2. Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function?
Does foo.py need or use bar.py to run?
YES - foo.py needs to be GPL3
NO - Why did you import it?"
WOAH THERE!!!!!
First off, for the 'NO'. Why would you import it?
try: from foo import interface; except: pass ## don't have neat extra feature
That is just one if thousands of examples. This is done all over the place in django app code, where one app can OPTIONALLY use features of another if it is installed on a machine. You don't include the open source package, but you can use it if it's installed.
So what this means (if you are correct), is that if I write some non-GPL3 code which can be compiled against ORACLE and PGSQL and a GPL3 database (all using the standard cursor interface), that I can not build against the GPL3 version unless my codebase is also GPL3?
That is what we are talking about here. I can have my GPL3 code talk to a proprietary module (which is done all over the place for things like ORACLE support in many GPL3 code bases), but you can not have a proprietary code base talk to a GPL3 codebase through an open published API?
I thought that was limited to GPL3 with the extra rider clause for things like web services.
Wow, stepped out for a few hours and there's a whole bunch of amazing stuff here. I'm still reading and thinking about all this, but I'll try to get through it all and have a follow-up tomorrow.
Here's what gets me:
The consensus seems to be that if foo.py includes 'include mercurial' (mercurial is GPL) then foo.py must be GPL. But...
1. If a web browser renders a page served from mercurial, must the web browser be GPL? (obviously not)
2. If a screen scraper that understands mercurial's data structure gathers data from a page served from mercurial, must the screen scraper be GPL?
3. If instead of scraping html mercurial is modified to serve JSON with urls and http get vars matching mercurial's api, must the client be GPL?
4. If instead of JSON some sort of transparent RPC library is used, must the client be GPL?
5. At this point adding the single line 'import mercurial' could switch the code from using proxied objects to using mercurial's objects directly in process. Must the client be GPL?
6. Someone adds that single line of 'import mercurial' to avoid the overhead of multi-process communication...
Ok, so 1 is white and 6 is black. 5 might be grey, but I don't see how using the api over rpc is significantly different than using it over rest/json. And rest/json isn't significantly different than screen scraping.
bleh.
MWM
Matthew: that's kind of similar to the plugin question. To me it seems entirely legitimate that someone can create a plugin to bridge between a GPL and proprietary piece of software. The plugin must be GPL, but the author of the plugin can't affect the licensing of the proprietary software (they simply have no rights), and the plugin can't be disallowed by the GPL (there's nothing in the GPL that bars a kind of code from existing; indeed that is contrary to several of the principles of the GPL). And really it's a valid way to scaffold the replacement of proprietary software. But it's also what everyone says you can't do.
And what you describe could indeed be the process where someone (neither GPL code author, nor proprietary software owner) bridges two systems. There are exceptions for system code, allowing for instance Turtle to bridge the proprietary Windows APIs and Mercurial. But I can imagine trying to bridge Photoshop and GIMP plugins (either consuming the other).
This is why I rely mostly on intention, as mushy as that is. If you go through all those steps as a bullsh*t way of justifying your GPL violation, that's no good. If you honestly go through those steps as a way to accomplish some reasonable end, that's okay.
Its pretty safe to say that the definition of "the public" is one or more people who would initiate a lawsuit over your use of the GPL code.
There are other licenses for software that's intended to be used in a different manner, so the GPL performs a very important function for the programmers who wish to write and release code under it.
These questions are probably well answered by the GPL FAQ, easily found using Google. Inviting ignorant comments with leading questions is not always such a good idea.
To start, whether or not a program is "commercially" released does not matter. Red Hat, for example, is commercially released under the GPL. You could say non-free or proprietary if that's what you mean.
In short, if you _distribute_ a product that contains GPL'd components you have to _make source available_ and allow changes and redistribution.
That's it. That should cover at least two thirds of your questions. The tricky part is what constitutes distribution and what decides if the component is a part of your product or not. That's where the corner cases are. Normally, linking is considered to make it a part while using a separate process for the non-free component does not.
But! If there's any doubt I suggest you send an email to the copyright holder and ask if your usage is ok. After all, it's his/her intentions that matter and not your own interpretation of it.
I'm not a lawyer so don't take this as legal advice.
1/2/3/4) yes
5) it changes, if there is a compatible implementation of libfoo.so not under the GPL. degrading gracefully to the compatible implementation, but still using features of the GPLed library does not count.
6) No. You have to give the user means to access the non-minified foo.js though.
7) yes.
8) yes, but only to the AR department, not on the web. you could have the AR department sign an NDA on the information contained in the source and give them the source. the NDA must be signed before conveyance of binary code.
9/10) same as 8.
11) no, because they don't fully own the copyright to Foo.exe's sources.
12) same as 8.
13) same as 8, so the mechanism that Initech uses to provide Jane the code does not change the answer. Jane could be bound anyway by the NDA.
14) same as 8 and 13.
15) no, the application is not distributed to them. they just happen to use it on the recruitment center's computer. Of course, if they're allowed (likely not) to plug in their USB drive and copy it, then they can ask for the source (and Initech had better have them sign an NDA before they get to the computer).
16) same as 15 part 2 (USB drive case).
17) definitely yes.
18) definitely yes.
19) yes. they can ask for the source, remove the password, and use the modified source. Furthermore, if it's GPLv3 and not v2, the password counts as Installation Information, so they must be given the password if they ask for, even if they don't plan on applying to the company.
20) They are not variations on a theme. in 15 the user is not allowed to make further copies (it is not conveyance). the answer to 17, 18, 19 is obvious. however, all other questions from 8 to 16 are variations on a theme. for them, the idea of an NDA associated to a GPL source code release is not well known. Once you grab it, you're okay.
IANAL.
Scary answers people! Pretty much every website out there is totally covered by the GPL! Time to start asking for the source code to them all.
@Paul Keeble
But the question is are they distributing the code? or just using it internally? (that's the reason why the agpl was invented)
The fact so many of the answer's seem to be 'it depends on the context, stupid!' is in itself a problem. It means no individual or organisation can even know whether a particular act will be in breach of the GPL without getting lawyers involved - and even then, they probably actually need to get sued before they will really know for sure. That isn't a productive legal framework to operate within.
...unless you are a lawyer.
First, the correct answer to almost all of these questions is "maybe." Anyone who comments that the answer is certainly yes or certainly no is either oversimplifying or misinformed.
Because there are no clear yes or no answers here, the outcome in any particular case is going to require an analysis of the particular situation and an acceptance of the legal and business risks involved with the decision.
Note that the FSF and SFLC will in almost every case take the GPL maximalist position, i.e., the position that gives the GPL the most scope. Also note that not everyone agrees that they are interpreting copyright law correctly.
1. foo.py is a Python library released under the GPLv3. bar.py is a library distributed commercially. If bar contains import foo, must bar.py be released under the GPL?
Maybe. This has not been resolved by the court, and the answer you get depends on who you ask. The FSF and SFLC will say absolutely yes. Mark Lemley and Larry Rosen would probably say no.
The relevant legal question is whether the interpreted file bar.py is a derivative work of the contents of foo.py. The fact is that copyright law doesn't mesh very well with software architecture, so the boundaries of what is a derivative work are very unclear. In this case, "import foo" is a type of runtime dynamic linking between the memory image created by interpreting two files. Is that memory image a derivative work of both of the input files? Almost certainly. However, it matters when, how, and by whom that memory image is created. There are good legal arguments on both sides of this issue because this is one of the grey areas that copyright was never intended to deal with.
The best advice is to act in accordance with the GPL as a social contract, as that will keep you out of the most trouble. In some cases, that means that bar.py must be GPL'd; in other cases it does not. If there isn't a project culture that allows non-GPL plugins, I would be very careful about doing so, and I would only do it after careful analysis and consultation with a copyright/software-savvy lawyer who can perform a derivative works analysis and advise on the legal risks.
2. Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function?
From a copyright analysis perspective, this isn't really different from #1. From a legal realist perspective, this is actually worse. With our legal system as it is, people who like good guys tend to win, and people who look like bad guys tend to lose, almost regardless of the merits of the case. This looks like a cheap dodge around the license terms, and getting in a lawsuit with these facts would tend to make you look like the bad guy.
3. Does the answer change if foo.py does not ship with bar.py and does not require its presence to function?
See above as to the answer depending on who you ask. In my experience, though, we track these situations separately because the argument that bar is not a derivative of foo is much stronger. Again, if you want to ship a commercial product this way, understand the possible risks.
4. libfoo.so is a C shared library released under the GPLv3. bar.rb is a Ruby library that uses Ruby/DL to call into libfoo (via dlopen() and friends). Must bar.rb be released under the GPL?
Again, the answer can vary depending on how closely bar and libfoo are intertwined. As with #3, however, we track this as a separate category of OSS integration, because there is better support for the idea that bar is *not* a derivative of libfoo. The specific answer, though, is fact-specific.
5. Does the above answer change depending on whether bar.rb is distributed with libfoo.so?
Legally no but practically yes. This tends to show tighter integration between the two, suggesting that bar.rb may be a derivative of libfoo. Again, however, the answer is fact-specific.
6. foo.js is a JavaScript library released under the GPLv3. bar.js is a library with all rights reserved. For performance reasons, I would like to minimize all my site’s JavaScript into a single compressed file called foobar.js. If I distribute this file, must I also distribute bar.js under the GPL?
This is an interesting question. If this question were examined in a court, I think that the most likely interpretation would be that foobar.js is a collective work, and the copyright of the two is separate. This would be analogized to the situation of putting files with separate copyrights into a single zip file or on a single disk.
7. foo.js is a JavaScript library released under the GPLv3. Bar.app is an application developed on the Mozilla platform using XUL. If Bar.app includes foo.js (via a <script> tag), must the source to Bar.app be released under the GPL?
Maybe. This is another tricky situation, and I don't think that any comment could be made without more facts and a deeper examination of the interplay between foo.js and Bar.app.
Now, before going onto the further questions, there are some pretty simple rules that you can use as to who gets the source:
- Internal/personal use of any kind is ok. The GPL explicitly allows unlimited freedom of use by an end user, including the types of integration that would be verboten if they were distributed to others. There was some confusion under the GPL (v2 in particular) as to whether outside contractors were "others" under the GPL; this has been clarified under v3.
- The source follows the binary. You don't need to give *everyone* the source; you need to give it to the people who receive the binaries from you. In practice, people frequently post the source for all to receive, but that is not necessary.
8. Foo.exe is an application released under the GPLv3. Initech’s HR department modifies Foo.exe for use internally....
No. Internal use.
9. IniSys is a fully-owned subsidiary of Initech. If Initech shares its modified version of Foo.exe with IniSys, does that trigger the GPL’s conveyance clause?
Probably not. Further, note that this would only require a release of the source to Inisys, not to everyone.
10. IniCom is a majority-owned subsidiary of Initech. If Initech shares Foo.exe with IniCom, does that trigger the GPL’s conveyance clause?
Probably not, but you would want to examine the relationship between the companies. Further, note that this would only require a release of the source to IniCom, not to everyone. As a practical matter, I would suggest conveying the source to IniCom.
11. Do either of the above answers change if IniSys or IniCom pay IniTech for the right to use (the modified version of) Foo.exe?
No.
12. Jane is a consultant hired by Initech. If Jane wishes to purchase Foo.exe from Initech for use in her consultancy, does that act trigger the GPL’s conveyance clause?
Probably yes, to Jane only. Note that Initech could have a separate clause requiring Jane to sell back Foo.exe at the end of her consultancy, including all copies.
13. Jane is a consultant hired by Initech....
This probably does not count as a conveyance, especially considering the discussion around v3.
14. As a standard practice, Initech requires that all consultants working with them use the modified version of Foo.exe....
Depends on the relationship between the consultants and Initech.
15. To apply for a job at Initech, potential employees must visit an Initech recruitment center...
No, it should not.
16. Initech now decides to make Foo.exe available to job applicants who wish to use their own computers...
Yes, probably.
17. Initech now decides that any job applicant may download Foo.exe ...
Yes.
18. Initech finally decides to simply let any applicant download Foo.exe from a public web server....
Yes.
19. This publically-available download of Foo.exe requires a password only available by calling Initech HR....
Yes. Note that in all these cases, the source must be released to those that receive the binary, not necessarily to the world.
20. The previous six questions are all variations on a theme. Is there a basic principle than enables them (and the other countless variations) to be answered quickly by laypeople?
See above.
Bonus question:
* I am a long-time open source user, producer, and advocate; my business revolves around open source consulting. My clients typically ask questions similar to the above. Is there a mechanism I can use to easily advise my clients in these matters, or must I retain a copyright attorney with GPL expertise?
I am sorry to say it, and discount this if you want, Jacob, but I would hire a lawyer if you are going to make business decisions based on these questions. There are a number of risks that need to be judged and taken on knowingly, rather than just answered by googling someone's blog comments. :)
One thing that I haven't seen mentioned in any of the comments is that the GNU GPL (any version) does not automatically require that your code be released under the same licence. It requires that your code be released under a _compatible_ licence. Under GNU GPLv2, you could also "scrape" a program's output to use the data (unless the data is also explicitly under the GNU GPL), but this may have changed under the GNU GPLv3.
So the authors of pyvcs (Alex Gaynor and Justin Lilly) would *probably* be safe for any licence under the scraping rules if they used the git/hg command-line interfaces, but not if they called libgit or libhg or equivalents directly. Even if they weren't safe under those rules, they would not be required to licence their code under the GNU GPL, but only under a compatible licence (MIT and BSD are the most well-known compatible licences).
Austin: GPLv3 does not say you can use a "compatible" license. It says of modified/derivative works, and I quote:
"You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy."
So, not "under a compatible license". Under the GPLv3, no exceptions.
@Morty Yidel
It doesn't matter what the GPL says in situations 2 & 3. What matters here is copyright law.
The GPL is a license that lets you create and distribute copies of certain software. You are only bound by the terms of that license when you need the license as a matter of copyright law.
In 2 & 3 you aren't distributing any GPLed software thus you need only abide by the GPL if it is a derivitive work of a GPLed program. As I said that's a complex question but it's one that can only be answered by looking at copyright law and precedent not the GPL. Moreover, if merely using an API makes your code a derivitive work of the library servicing the API it's hard to see how programs like WINE aren't infringing.
Clear and concise answers.
#1: No. For instance, there is GPL software importing Windows API which is not free. GPL software can depend on non-free/non-GPL, because when you write GPL code, you are the author and you decide whether you want to enforce the license as you wish. However, non-GPL software cannot and shouldn't depend on GPL software because dependence is considered to be a "derivative work" and is covered by the license.
#2: No.
#3: No.
#4: Yes, because bar.rb is a derivative (depends on) libfoo.so. Of course, there should be intermediate bindings which must depend on libfoo.so and thus be GPL too. Please note that most libraries are using GPLv3 + Linking exception, or LGPL v2 which means that dependence and linking (whether dynamic or not) are not considered as "derivative work". For instance, everyone can use the glibc (GPL + linking exception), distributed along gcc (GPL) and link proprietary or non-GPL programs.
#5: If bar.rb is distributed with libfoo by the same authors, the authors are free to provide an exception that allows bar.rb to have a non-GPL license or another exception, but truly it doesn't change anything that it would be distributed together or separately.
#6: Yes. Once again, derivative work, because in copyright law a single file cannot have different licenses for different parts. Otherwise, there would be no problem.
#7: Yes. <script> is linking.
#8: No. Within a given moral entity, this is not considered as distribution. Generally speaking, the GPLv3 only states that the recipient is entitled to get the actual code (recipe) in a decent fashion (modifiable). If the recipient is the same entity/doesn't care about the source, there is no problem, is there? That is, the Accounts Receivable dpt could sue Initech's HR dpt ;).
#9: No again. Same answer. But why would anyone hide code in the same corporation? Those questions make no sense.
#10: It depends. If the recipient wants the code, they have to get it. Same entity or not. If there is schizophrenia within a company the least of their concerns is the GPL. But if the company isn't fully owned, I guess the smaller shareholders should make sure they get the code.
#11: No. Answering the general idea here: if the authors of a GPL software distribute it, and are the full authors, they can dual-license it and provide a proprietary version (usually for a free, here they sell a proprietary license). But GPL software can be sold too, and it doesn't change the license.
#12: The question that lies here is whether Jane is considered to be a separate entity, and whether giving her the program accounts as redistribution. I guess it's up to Jane and her consultancy contract which should include an NDA. But of course there is a clash between the GPL and her contract, and only a judge can decide how it would work. The GPL states that if Jane gets the code, she has a right both to change it, and redistribute it, and that if it cannot be done, then the program should not be distributed. I guess that if Jane wants to keep on consulting for IniCom, she won't distribute the code.
#13: I don't understand. If they provide the code for review, what is the problem? Of course, GPL'ed code remains GPL'ed code. And derivative work the same.
#14: Yes. Modified version = derivative work = GPL. Answer did not change though. The consultants' work is likely under an NDA, which they signed and binds them.
#15: Not at all. Merely using a program does not count as distribution.
#16: Yes. If the program is distributed, the applicants have a right to demand the source code. I guess an NDA could work here too, with the legal uncertainties that goes with it.
#17: Same answer. Yes. Download or disk or VPN, or whatever, this is distribution. I guess entering the VPN could be an occasion to accept an NDA.
#18: Same answer.
#19: Yes.
#20: Yes. I believe I answered that already. Any public person who gets a GPL'ed program is entitled to get the actual code (of course, the "cleaned" up code without hardcoded passwords & such, only in terms of functionality). And if you get someone to sign a contract (NDA, employment contract, etc), they're not a "public person" anymore, depending on the contract they accept.
Bonus: I believe a simple automaton can describe the GPL in terms of software. No need for an attorney except when you want to enforce the GPL (or are sued, of course).
I hope I gave enough pointers to how the GPL work. Think of "dependence" and "derivative work", and whether it makes sense : for instance if I program a GPL'ed software that runs on a proprietary platform, it is *my* choice to use the GPL and it would make no sense to make it illegal to run on the very platform it runs on :). Don't forget there are other variants of the GPLv3 with different rules: Linking exception: more permissive, because linking/dependence is not a "derivative work" anymore ; AGPL: less permissive, because online usage is considered distribution ; and many more tailored to suit your own needs, like MySQL's GPL exception to allow PHP to use libmysql.so (GPL'ed) without being GPL'ed.
There is a lot of FUD that transpires through your questions, but the GPL is nothing more and nothing less than a tool for developers who wish to get code modifications back and create a full free software stack. The only bridge between the two worlds is the GPL + Linking exception / LGPL.
@Simon Chemouil, if you read the GPL2 and the GPL3 you'll notice there are exceptions for linking or running within a proprietary operating system. This allows a program programmed for linux to be ported to windows. This doesn't except this case. Thus your reasons for 1/2/3 are erroneous.
@Peter Gerdes, your intent in both cases is to USE GPL software without GPLing your software. The intent is to avoid the GPL by not distributing software that is GPL but link later. Do you think you'll get a judge who will ignore such an intent? If the author of the GPL'd software wanted you to link to his work but not license he wouldn't have used a straightforward GPL or he would've allowed a linking exception. You can't suggest I'm ignoring the law here, the law also includes those who interpret and execute the law. In a GPL case, don't you think more evidence than just a license would be used? If they used the FSF's GPL faq it'd be painfully clear that the GPL was designed to disallow this kind of behaviour.
Since neither of us are lawyers or judges, what I suggest is that we cover our butts and avoid lawsuits over things like that by not violating the spirit of the license.
This is evident in: http://gplv3.fsf.org/gpl-ra...
The paragraph following subsection 5c has been revised for clarity, but the underlying meaning is unchanged. When independent non-derivative sections are distributed for use in a combination that is a covered work, the whole of the combination must be licensed under the GPL, regardless of the form in which such combination occurs, including combination by dynamic linking. The final sentence of the paragraph adapts this requirement to the new compatibility provisions of section 7.
Now what does the GPL3 say:
[5] c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
By those terms alone it seems painfully clear that any attempt to avoid GPLing linked code through seperate distribution is viewed as a violation of the license itself.
1. Unknown, consult a real lawyer or buy a license for foo.py. I personally would play it safe and assume that bar.py needs to be GPL in this situation.
2. This question is why IP lawyers make lots of money. If you provide a clear interface that can be clean-room implemented to replace foo.py, it would be ununlikely that you would need to GPL bar.py. If there was no way to implement foo.py in a clean room environment it would probably go towards the other side. Either way, this situation is legally dangerious and a competent lawyer should be contacted and relicensing of foo.py should be considered if bar.py is to remain non-GPL.
3. Confusing, but a good lawyer could argue it would exactly as with #2. Again, the safe solution would be to get foo.py relicensed for your needs or GPL bar.py.
4. Yes.
5. No, though see #2 for discussion of clean-room workaround to licensing.
6. Yes, textual inclusion is a clear derivitave work. Contact author and get foo.js relicensed for your needs or GPL foobar.js.
7. Yes, though a good lawyer could make the case muddy enough that you could win. Safe bet is to get foo.js relicensed.
8. No, the departments are not separate legal entities.
9. Contact a real lawyer. Answer is probably yes -- IniSys will need granted access to the source code.
10. This situation is identical to #9.
11. Contact a real lawyer. It's not clear what they would be able to sell however, without getting a commercial licenses for the original Foo.exe.
12. Yes. Jane (corp?) is a separate legal entity buying code in excess to the consultant contract. However, as with #11 it's not clear that IniTech has anything they could sell without getting a commercial license from the original author.
13. This situation is identical to #9.
14. This situation is identical to #9.
15. No, there was no distribution.
16. Yes, this is distribution. Job Applicants are not employees.
17. Yes, this is distribution. Job Applicants are not employees.
18. Yes, this is distribution. Job Applicants are not employees.
19. Yes, this is distribution. Job Applicants are not employees. GPL distribution is not circumvented by crippling the executable.
20. Are you distributing GPL products to a legal entity that did not write them? Then you need to send the source under the GPL.
I missed your bonus question when replying before. I would highly recommend keeping a copyright lawyer on retainer if you are often dealing with matters of copyright law as a main business activity.
I would also recommend against advising your clients in any legally dubious situation unless you have a serious liability waiver in writing.
That said, you should have no problem avoiding answering questions like this in the normal course of business, because they are really questions for lawyers not copyright users.
@Morty Yidel:
Indeed, there are explicit exceptions for "major components" (including the operating system) but I do not believe those exceptions change the semantics of the GPL (ie, they are only here to make things clearer).
For instance, take a proprietary piece of software with an usual license (EULA) with the possibility to write modules. E.g: Visual Studio. I can very well make a Visual Studio plugin under the GPL. What then? Visual Studio is not going to switch to the GPL anytime soon as far as I know, so should I be forbidden to distribute my plugin?
No, because it runs on VS, there is an implicit exception for VS (very similar to the explicit exception of "major components").
Why is that? Because the GPL is a standardized license, but it is my piece of software (plugin), at the end of the day I choose the license I want.
Visual Studio does not enforce anything on the license of 3rd party plugins, so I am free to choose the GPL. Of course, this is not the "vanilla" GPL, but this is very common. Actually, the FSF would encourage me to call the (very slightly amended) plugin license "GPL" as to avoid confusion and license proliferation, because I could very well write "My Very Own License v2" that states exactly the same stuff as the GPL but allows my plugin to run on VS.
This implicit exception is set by the original copyright holders and must be accepted by future contributors.
When, later on, I propose my GPL'ed plugin for download, other developers wishing to modify the code will know their rights and duties because "GPL" is easier to understand than "My Very Own License". Of course, if you diverge too much from the purpose of the GPL (that is, if you add exceptions that are not in the spirit), the FSF will ask you nicely to call your license differently.
Searching the Internet using Google and "GPL FAQ" yields this as the first hit:
http://www.gnu.org/licenses...
I trust that this resource will inform the debate. Maybe Jacob filtered his questions against the above; maybe not.
I think it's worth pointing out that if the code in question in every case is just licensed under the GPL (or less restrictively) then all these questions go away.
So basically, all these questions seek clarification on how to share the least code with others. If you're happy to share everything, then these questions are not important.
Simon,
I believe your analysis of VS modules is wrong. In the situation you describe VS displays a copyrighted interface for creating modules. VS grants explicit permission to use this interface with copyrighted code. The interface is general to any module, and there is no way it could possibly end up being derivative of a module that was written using the public interface.
Sean
Folks ... read what VanL wrote above. He's probably the only lawyer/programmer amongst you.
Ditto - read VanL.
And to clarify some of my underinformed wonderings earlier in the thread: the FSF FAQ states clearly that you CAN develop modified versions of GPL software for internal use only, and even consider it a trade secret, as long as you never give that program to anyone outside your company/organization. And if the software is stolen by a "disgruntled employee" and made public, you are NOT bound by the GPL, because you did not intentionally distribute the software.
http://www.fsf.org/licensin...
My one quibble with VanL is that it's not really fair to say the FSF always claim "maximal" scope for the GPL. They may claim a relatively broad scope (for instance, on the issue of Python "import" as linking), but their FAQ is full of examples where they limit the GPL's scope.
And, of course, ditto to everyone saying that if you're making business decisions on legal issues (any legal issues, nothing special about GPL) you should consult an actual lawyer.
@Sean
I think I was wrong on a point but not on what you call me for :). Because the discussion was whether and why GPL works on proprietary software, is the full software stack isn't GPL'ed.
Here, of course a VS plugin is not "derivative work", but it is still "dynamically linked" which is a requirement for GPL compatibility. I quote the GPLv3:
"For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work."
As Morty said, the GPL states that there is an exception to run on proprietary software because it is a "major component". I said that exception was explicit but not necessary. After careful thinking, I believe I was wrong, because being GPL'ed does not only mean that the software license must *behave* like the GPL, it must *be* the GPL so that it remains compatible with other GPL-licensed software.
I cannot add an exception to my GPL licensed software then link it to another GPL'ed software, because it would have compromised the license of the software I link to (which states only GPL is ok, not GPL+exception).
Thus, Morty was right that the exception for major components is the reason this all works (and when I write a GPL'ed plugin for VS, VS is a "major component" without which the plugin has no reason to exist).
Jacob, I guess in the end, the GPL intents are simple: the user of your software should have access to that very source code. It's all about your user freedom to know how the product it uses was made.
So, from #1 to #7: it doesn't matter, because you're not getting GPL code, modifying, and distributing without the source.
#8 and on: GPL code is getting modified, so the user of this software (subsidiaries and such) should have access to it's source as well.
Nothing in the GPL requires weird relicensing neither releasing source to everybody. If you acknowledge that the main point is giving the software user also access to the code, the intents are pretty clear.
At my day job, I'm a professional GPL enforcer and Free Software licensing analyst. But, on the weekends, I'm a software consultant as you, and I have to advise clients in the same way you do. So, I focus my answer only on the bonus question. Here's what I say to clients in those situations: "GPL'd software is designed to give freedom to as many users as it can under copyright law. I recommend you GPL your stuff, no matter whether the GPL legally requires you to do so or not, because I think that's best for humanity. However, if you don't want to, you should retain your own copyright lawyer to figure out what you don't have to release as GPL-compatible Free Software."
This may sound like a cop-out, but in fact, it's worked for me numerous times to convince clients just to release the stuff anyway because it's easier to do the right thing, once they realize it won't really hurt them.
For the non-bons questions, I'll give a meta-answer: if you are working on a Free Software project operating in a not-for-profit way, the SFLC exists to help answer these sorts of questions, pro bono. SFLC doesn't provide this service to for-profit endeavors, however, many times the non-profit projects publish guidelines to help the for-profit businesses operating around their codebase. Wordpress, for example, recently did this with SFLC's advice.
Just wondering are there any statistics available on the net that shows the current market share of various licenses. i.e. GPL vs. MIT vs. Apache etc.
It would be interesting to which license are preferred by developers and what license are being used by business? I can speak for my consulting business alone and I can say over the years I have seen my customers are more reluctant to MIT and Apache then other licenses. I am curious to know how is it for you Jacob?
Cheers
Anton
I know that personally I've been struggling with issues #1 and #2 for the Xapian Haystack backend I've been working on. Unfortunately, it appears as though, because Xapian is GPL and Haystack is MIT, there's no way it can ever be packaged together without subverting the Haystack license (forcing it to become GPL).
So, for me at least, in this case, GPL is taking away freedom.
The ambiguity of the GPL is only a problem if you're trying to find a way around it.
The answer to "if I do this fancy trick to get around the GPL will it work?" is usually "maybe" and therefore you shouldn't do it.
If you use GPL released code in the spirit of the GPL and software freedom then it's not ambiguous at all.
Leave a comment: