If they are in the same memory space they are linked and fall under section 6, but since you aren't distributing a binary image of the memory space you are not limited by license.
Section 5 is for the case where you are not distributing the library -- like most proprietary software on GNU/Linux and glibc. If you're distributing a library and something dynamically linked to it, you need to follow section 6.
I disagree that the definition of linking we use is different from everyone else's. And I disagree that proprietary software vendors will avoid LGPL software -- given the amount of high-quality LGPL libraries available, they will make the rational decision: it's better to not have unenforcable clauses in their license than to reinvent the wheel. Ten years of history shows that the LGPL is popular and effective.
No, but by your definition, it does need to allow reverse engineering and modification for personal use.
That's not acceptable to a closed source project,
It's clearly been acceptable to proprietary software companies for years, as reverse engineering happens whether or not licenses allow it. Everyone knows that software is going to be reverse engineered if it's any good at all.
What I mean is that functions from program A call (directly or indirectly) functions from library B. You bring up "grep", but that doesn't matter -- it's not a library under the LGPL (instead, it's a program under the GPL, which doesn't mention linking).
This means that any Java program could be treated as a 'library facility', and therefore appears to come under the scope of section 7, rather than section 6. And, as far as I have been able to deduce from the phrasing in section 7 (it isn't altogether clear), it seems that in order to distribute a work under section 7 I must permit further redistribution of my 'work based on the library'.
I don't think jars for executables qualify as "library facilities".
I agree that the comment was not particularly polite. But I was quite angry at the way Slashdot treated me -- they posted an article misparaphrasing me utterly. This cost hours of my time to correct, and I will now get questions about it for the next several years. And they didn't even bother to call or email me. Next time, I'll just be more straightforward about it, and call CowboyNeal an unprofessional jerk.
Could someone clarify this statement? What if I release a non-open source app that links to a LGPL lib and am perfectly willing to let users replace the old jar with a new version of the LGPL lib, but when they do so it breaks my app due to some change in the interface of LGPL lib (or whatever)?
This is, of course, a possibility.
Am I somehow obligated then to either a) fix my app if the new lib version breaks it or b) release my non-open code so someone else can fix it?
Does this mean we can't obfuscate the java bytecode to prevent decompilation ?
Or does this just mean that the proprietary software using the LGPL library must not forbid modifications of itself to its user (as fair use) but it does not need to make them easy.
Furthermore, if that's the case, nobody should ever use LGPL'd libraries, as it definitely *is* viral in nature. Your definition is contrary to the popular view of the LGPL.
This is simply not true! The LGPL's section 6 (the section in question) allows you to link proprietary software to a LGPL library.
By your definition, if I distribute a DLL in the same installer as code that calls upon that DLL, and the DLL is open sourced and LGPL'd, then the code calling that DLL now has stigma attached to it that, most likely, the maker of the DLL didn't intend to attach to it and that the creator of the code had no idea that was there.
Whoa, what "stigma"? Do you mean that the calling code must be LGPL? That's not correct. But the calling code must obey the small restrictions in section 6 of the LGPL. The goal of these restrictions are to make sure you can link in new versions of the LGPL library.
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, period.
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, without getting the most definitely undesirable stigma of section 6 attached to the code.
Section 6 says is that you have to make sure that people can relink in new versions of the LGPL library, and can reverse engineer and modify (but not redistribute) your program for personal use. You don't have to provide source code for your application, and you can license it under a proprietary license.
Your definition requires more than that, and thus the LGPL doesn't do what everybody has thought it did for the past X years.
It's true that not many people knew about the reverse engineering stuff in Section 6. But the LGPL does have more-or-less the same meaning as everyone has always thought it did.
According to your definition, it appears that any two binaries loaded in memory, where on calls the other, are "linked", regardless of wether or not the code is mingled in its distribution.
I would say that that's not true. However, certainly if the two are in the same memory space, they are linked. And it's also true that you can't circumvent the (L)GPL by building wrappers, which is hardly news.
Distributing a jar, along with some code which will end up calling code from that jar, is linking to that jar. The actual bindings are resolved at runtime (although as I understand it, the jar needs to be present at compile time too), but it's still linking.
1. Make sure your licensing follows the simple requirements in the 1st para of section 6.
2. Provide the LGPL library in a separate jar, and allow that jar to be replaced by newer versions of the library. This is only one of the possible ways to comply, but it's certainly the easiest.
3. Make available the source code for the LGPL library.
Re:FSF's interpretation are not very relevant
on
LGPL is Viral for Java
·
· Score: 2, Informative
Technically, when you "LGPL" your code, you sign away license rights for that software release to the FSF. That is why if someone violates the license of your GPL'ed program, the FSF can step in (with their lawyers) to defend your licensing rights.
That's not true. FSF can only enforce the (L)GPL for programs on which FSF holds copyright.
Oh, wait, now I actually read your post, and realize that you are still completely confused. Sorry.
Let me make it clear: Section 6 is not what you think it is.
You think section 6 says:
You must cause any work that you distribute or publish, that links to the Library, to be licensed as a whole at no charge to all third parties under the terms of this License.
Section 6 actually says:...distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
Note that this does not require the provision of source code, nor does it require allowing the original program or modifications thereof to be distributed.
I cite the greater good that this will hopefully increase awareness of the obligations created under the LGPL.
Instead, you have confused the issue further.
Most people believe that using an LGPL library does not place any additional obligations on the person using it, so long as they don't modify the library itself. Section 6 contradicts that popular belief.
I agree that this is a common false belief. However, Section 6 is far from secret, and anyone who distributes software should read the license before doing so.
Similarly, people might quite reasonably believe that using a late-binding language is a way out of being considered "linked" to the library.
FSF has always had the same views on this -- it's not really a surprise.
The problem is that CowboyNeal didn't call me first.
As a result, the article gives the wrong impression -- it implies that the LGPL is broken with respect to Java. In fact, it is not. Section 6 works for Java in the more-or-less the same way it works for C.
Hi. I'm that David Turner who is quoted. I'm not the David Turner who works for Microsoft, and I do not hack on Freetype.
First, I'm upset that CowboyNeal didn't contact me -- as the article says, I work at the Free Software Foundation, and you can find our phone number on our web page by searching for "s" on Google and clicking "I Feel Lucky."
Now, if you read section 6 of the LGPL, it's not the same hereditary [1] thing as section 2 of the GPL -- what it says is that your program, which links against the library, does not need to be licensed under the LGPL. But you do have some obligations -- you need to allow people to relink your code with new versions of the library.
[1] I think hereditary is a much better analogy than viral, and I thank the person who came up with it and whose name I forget.
The article cited Dalzell's opinion in the CDA case, but didn't explain the most important part: the difference between the internet and radio. If I don't like your weblog entry, I can post my own entry in my own weblog criticising it. If I don't like your radio comment on me, what can I do? I can't start my own radio station, because there's limited spectrum. The limited amount of spectrum is only reason the FCC can regulate the content of radio in the first place. So, a right of reply make sense in the radio context, where otherwise you might have no forum. But on the internet, everyone has a forum, so a right of reply is unneeded.
I've also seen some people here claim that it's not an imposition on freedom of speech because you can still publish what you want, or that it *is* an imposition because it will have a "chilling effect." I think these people miss the point. The reason it violates freedom of speech, is because it's *compelled speech* -- it's the government mandating that I have to publish things I disagree with. In radio, where there's limited spectrum, everyone has to sacrifice. But on the 'net, there's no need for that.
Usually, we don't do much investigation -- we rely on reports from users of the products. We never agree to EULAs, technical NDAs, etc. as a matter of principle. And usually, there's no disassembly involved -- simply grepping for a copyright notice is enough. Most violations are inadvertant -- they're still serious, but there's usually no attempt to hide what software is used.
Slashdot Mirror
Local storage on the kiosks should be encrypted with a public key, for which the corresponding private key is stored at the central server.
I'm not going to respond to any more of this nonsense on Slashdot. You're intentionally misinterpreting everything I've said.
If they are in the same memory space they are linked and fall under section 6, but since you aren't distributing a binary image of the memory space you are not limited by license.
Section 5 is for the case where you are not distributing the library -- like most proprietary software on GNU/Linux and glibc. If you're distributing a library and something dynamically linked to it, you need to follow section 6.
I disagree that the definition of linking we use is different from everyone else's. And I disagree that proprietary software vendors will avoid LGPL software -- given the amount of high-quality LGPL libraries available, they will make the rational decision: it's better to not have unenforcable clauses in their license than to reinvent the wheel. Ten years of history shows that the LGPL is popular and effective.
No, but by your definition, it does need to allow reverse engineering and modification for personal use.
That's not acceptable to a closed source project,
It's clearly been acceptable to proprietary software companies for years, as reverse engineering happens whether or not licenses allow it. Everyone knows that software is going to be reverse engineered if it's any good at all.
What I mean is that functions from program A call (directly or indirectly) functions from library B. You bring up "grep", but that doesn't matter -- it's not a library under the LGPL (instead, it's a program under the GPL, which doesn't mention linking).
This means that any Java program could be treated as a 'library facility', and therefore appears to come under the scope of section 7, rather than section 6. And, as far as I have been able to deduce from the phrasing in section 7 (it isn't altogether clear), it seems that in order to distribute a work under section 7 I must permit further redistribution of my 'work based on the library'.
I don't think jars for executables qualify as "library facilities".
I agree that the comment was not particularly polite. But I was quite angry at the way Slashdot treated me -- they posted an article misparaphrasing me utterly. This cost hours of my time to correct, and I will now get questions about it for the next several years. And they didn't even bother to call or email me. Next time, I'll just be more straightforward about it, and call CowboyNeal an unprofessional jerk.
It's not true that code linked to and distributed with an LGPL library needs to be licensed under the LGPL.
Could someone clarify this statement? What if I release a non-open source app that links to a LGPL lib and am perfectly willing to let users replace the old jar with a new version of the LGPL lib, but when they do so it breaks my app due to some change in the interface of LGPL lib (or whatever)?
This is, of course, a possibility.
Am I somehow obligated then to either a) fix my app if the new lib version breaks it or b) release my non-open code so someone else can fix it?
Neither.
Does this mean we can't obfuscate the java bytecode to prevent decompilation ?
Or does this just mean that the proprietary software using the LGPL library must not forbid modifications of itself to its user (as fair use) but it does not need to make them easy.
The latter.
Furthermore, if that's the case, nobody should ever use LGPL'd libraries, as it definitely *is* viral in nature. Your definition is contrary to the popular view of the LGPL.
This is simply not true! The LGPL's section 6 (the section in question) allows you to link proprietary software to a LGPL library.
By your definition, if I distribute a DLL in the same installer as code that calls upon that DLL, and the DLL is open sourced and LGPL'd, then the code calling that DLL now has stigma attached to it that, most likely, the maker of the DLL didn't intend to attach to it and that the creator of the code had no idea that was there.
Whoa, what "stigma"? Do you mean that the calling code must be LGPL? That's not correct. But the calling code must obey the small restrictions in
section 6 of the LGPL. The goal of these restrictions are to make sure you can link in new versions of the LGPL library.
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, period.
This is false.
In other words, by your definition, it's utterly impossible for anyone making code that uses any LGPL library of any type to create one distribution file that includes both the code and the LGPL'd library, without getting the most definitely undesirable stigma of section 6 attached to the code.
Section 6 says is that you have to make sure that people can relink in new versions of the LGPL library, and can reverse engineer and modify (but not redistribute) your program for personal use. You don't have to provide source code for your application, and you can license it under a proprietary license.
Your definition requires more than that, and thus the LGPL doesn't do what everybody has thought it did for the past X years.
It's true that not many people knew about the reverse engineering stuff in Section 6. But the LGPL does have more-or-less the same meaning as everyone has always thought it did.
According to your definition, it appears that any two binaries loaded in memory, where on calls the other, are "linked", regardless of wether or not the code is mingled in its distribution.
I would say that that's not true. However, certainly if the two are in the same memory space, they are linked. And it's also true that you can't circumvent the (L)GPL by building wrappers, which is hardly news.
Distributing a jar, along with some code which will end up calling code from that jar, is linking to that jar. The actual bindings are resolved at runtime (although as I understand it, the jar needs to be present at compile time too), but it's still linking.
With a hex editor.
The LGPL isn't the GPL. If you want the GPL, you know where to find it.
1. Make sure your licensing follows the simple requirements in the 1st para of section 6.
2. Provide the LGPL library in a separate jar, and allow that jar to be replaced by newer versions of the library. This is only one of the possible ways to comply, but it's certainly the easiest.
3. Make available the source code for the LGPL library.
Technically, when you "LGPL" your code, you sign away license rights for that software release to the FSF. That is why if someone violates the license of your GPL'ed program, the FSF can step in (with their lawyers) to defend your licensing rights.
That's not true. FSF can only enforce the (L)GPL for programs on which FSF holds copyright.
Oh, wait, now I actually read your post, and realize that you are still completely confused. Sorry.
...distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
Let me make it clear: Section 6 is not what you think it is.
You think section 6 says:
You must cause any work that you distribute or publish, that links to the Library, to be licensed as a whole at no charge to all third parties under the terms of this License.
Section 6 actually says:
Note that this does not require the provision of source code, nor does it require allowing the original program or modifications thereof to be distributed.
I cite the greater good that this will hopefully increase awareness of the obligations created under the LGPL.
Instead, you have confused the issue further.
Most people believe that using an LGPL library does not place any additional obligations on the person using it, so long as they don't modify the library itself. Section 6 contradicts that popular belief.
I agree that this is a common false belief. However, Section 6 is far from secret, and anyone who distributes software should read the license before doing so.
Similarly, people might quite reasonably believe that using a late-binding language is a way out of being considered "linked" to the library.
FSF has always had the same views on this -- it's not really a surprise.
The problem is that CowboyNeal didn't call me first.
As a result, the article gives the wrong impression -- it implies that the LGPL is broken with respect to Java. In fact, it is not. Section 6 works for Java in the more-or-less the same way it works for C.
Hi. I'm that David Turner who is quoted. I'm not the David Turner who works for Microsoft, and I do not hack on Freetype.
First, I'm upset that CowboyNeal didn't contact me -- as the article says, I work at the Free Software Foundation, and you can find our phone number on our web page by searching for "s" on Google and clicking "I Feel Lucky."
Now, if you read section 6 of the LGPL, it's not the same hereditary [1] thing as section 2 of the GPL -- what it says is that your program, which links against the library, does not need to be licensed under the LGPL. But you do have some obligations -- you need to allow people to relink your code with new versions of the library.
[1] I think hereditary is a much better analogy than viral, and I thank the person who came up with it and whose name I forget.
The article cited Dalzell's opinion in the CDA case, but didn't explain the most important part: the difference between the internet and radio. If I don't like your weblog entry, I can post my own entry in my own weblog criticising it. If I don't like your radio comment on me, what can I do? I can't start my own radio station, because there's limited spectrum. The limited amount of spectrum is only reason the FCC can regulate the content of radio in the first place. So, a right of reply make sense in the radio context, where otherwise you might have no forum. But on the internet, everyone has a forum, so a right of reply is unneeded.
I've also seen some people here claim that it's not an imposition on freedom of speech because you can still publish what you want, or that it *is* an imposition because it will have a "chilling effect." I think these people miss the point. The reason it violates freedom of speech, is because it's *compelled speech* -- it's the government mandating that I have to publish things I disagree with. In radio, where there's limited spectrum, everyone has to sacrifice. But on the 'net, there's no need for that.
Usually, we don't do much investigation -- we rely on reports from users of the products. We never agree to EULAs, technical NDAs, etc. as a matter of principle. And usually, there's no disassembly involved -- simply grepping for a copyright notice is enough. Most violations are inadvertant -- they're still serious, but there's usually no attempt to hide what software is used.
Er, you can mail me at novalis atsign fsf.org if you have any information.