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.
Google used some GPL code right behind the button "I am feeling lucky". So the button, using the GPL code, is infexted and behave accordingly. It's a perfect illustration that the viral nature of GPL is not bad - it's rather very useful.
"I am David Turner! My Pagerank is SO MUCH BIGGER than your Pagerank! My organization is the number one Google hit for ONE LETTER of the alphabet! Ph33r m3!"
What a smarmy comment that serves no purpose and is absolutely irrelevant. Quite like the content of FSF licenses actually.
--- My software doesn't have a philosophy. It just works.
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.
I apologise for fudging the issue somewhat (i.e. not explaining what "considerable GNU-ness" means) in order to make the post sensationalised enough for Slashdot to post. I cite the greater good that this will hopefully increase awareness of the obligations created under the LGPL.
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. Similarly, people might q
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.
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.
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.
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 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.
I was talking about a technical point of view? How does a person use a lgpl java jar in a way that complies with section 6 of the lgpl. The people who wrote the blogs don't seem to know it.
It might be usefull to know this for other programming languaes too? maybe a nice Idea for in the faq.
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.
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.
Assuming you didn't modify the LGPLed code, is it sufficient to provide a link to the authors distribution of the source? Basically, do I have to host the source or just tell you where to get it?
Okay, if I make a piece of java code, like a class, and provide methods to use that class, and wrap this up in a jar file and say it's now under LGPL, then here's what somebody should be able to do (IMO):
1. Create java code which uses my library (jar file) with the library as a separate jar file (ie., none of my code is in their code, they're just calling methods and classes from my code).
2. Not have any requirements placed upon their code at all in any way.
As I see it, this is exactly what the LGPL does. Section 6 never comes into play whatsoever, because their code falls into section 5. They haven't actually combined my code into theirs, it's totally separate, sitting right in that jar file (aka library).
Granted, if they modify my code and distribute the modified version, then they must distribute the modifications they made to my code as well. That's what the LGPL is for in the first place.
But I fail to see how section 6 applies in any way whatsoever. None of my LGPL'd code is included in their code in any way. It's separated because it's in a separate jar file.
Lookie here: 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
To me, this exactly describes someone calling classes or other code that resides in my jar file. They're not copying the code into their own jar, they're linking to it. But let's look at section 6:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library...
This never happens if done properly. My jar is sitting alone, their jar is sitting alone. At runtime, their jar loads, says to the java interpreter "hey, make a class from that other jar", then my jar loads and a class gets created.
So, am I wrong here? I see no normal situation in which section 6 would ever apply to Java libraries, unless someone was straight up ripping my classes off and including them in their own jar file along with their own code.
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.
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.
If you use this as your definition of "linking", then "linking" loses all purpose and meaning.
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 cod
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.
I would say that that's not true. However, certainly if the two are in the same memory space, they are linked.
Define "same memory space".
On (modern) Intel-based CPUs, most OS's run in a single 32-bit memory segment. Is all code loaded into the same segment (which would be everything) now considered "linked"?
Or how about programs written for PC (or MS) DOS, where there is absolutely no memory virtualization or protection. _EVERYTHING_ lives in the same memory space -- does that make the command interp
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).
However, certainly if the two are in the same memory space, they are linked.
That is nonsense. 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.
You most certainly can circumvent the LGPL by building wrappers since doing so creates a work in isolation.
If any link in memory space means that the linked programs are restricted in license then running most proprietary code on a GN
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.
Section 5 is for the case where you are not distributing the library
You are trying spin the definition of "program" as "the sum of all parts distributed in an archive in order to make a program work, regardless of whether or not those parts can be easily obtained separately." I don't buy it. The software I've written placed into my jar is my "program". By saving the user the trouble of having to find those components and install them himself your claim that other jars in my.zip/.tar.gz are now infect
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.
That's the most wacked out crazy way to look at linking I have ever heard, and if that is in fact the case, then the LGPL is severely broken and should never be used in any circumstances whatsoever, by anybody.
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.
The whole point of the LGPL is to create libraries that are open source but which can be used by closed source programs, requiring only that any modifications to the *library* be
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 p
Could you kindly tell me what exactly this hole is?
Is it really that important to you that your clients/customers be unable to discover that you used a piece of LGPL'ed code? Is it important that they be unable to discover how you used that library?
I see. So the fact that it is difficult for them to do so (you didn't after all hand them the source) makes no difference?
That is, you appear to be placing great emotional weight on the idea that the user should not have the legal right to modify their copy of the bits that constitute your work.
Is it the fact that the user might change their copy what offeends you?
Or is it the second half of that sentence, that the user might while debugging discover the full details of how your software works?
Ok, I think I see the difference in our positions: if I'm getting paid for a copy of my code, I don't really care what the user does with it. They still can't redistribute it to someone else (legally), and are free to attack it with a hex editor all they want. (Just so long as they don't expect me to put it back together) Note that it doesn't make a difference to Id Software if someone patches their own DOOM wad files so that the bad guys look like Barney.
As I see it (prizog, please correct this), the situation is this:
If you create a single distribution file containing both your own work and a LGPL'ed java library, then you must also provide a way for the user to replace the LGPL'ed portion with any subsequent version of that library. (where "subsequent version" means "any binary-compatible library the user has access to")
The means to do this would depend on exactly how you created the distribution file. If, as with some things we have made at work that
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
I agree that it could cause precisely that effect. The bad thing about having to distribute it in parts (or worse distribute half of it with instructions how to get the other parts) means, unless it's targetted at businesses or other techies, it ain't gonna sell. Will Joe six pack be able/willing to insta
It's not true that code linked to and distributed with an LGPL library needs to be licensed under the LGPL.
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, and is a very big reason not to use the LGPL. It's also non-sensical, non-intuitive, and not the way that any normal person would read the document and understand it because of your wacky way to define "linking".
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.
...reverse engineering happens whether or not licenses allow it. While that's true, it's also irrelevant. What license have you seen for any major product that doesn't have "you agree not to blah, blah, reverse engineer, blah.." in it?
Such a strange definition being used for linking forces companies into Section 6, and therefore they won't be adopting open source libraries, and won't be contributing back to those libraries.
Look, guy, you can argue this all you want, but in the end, your definition of "lin
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.
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.
I think you're failing to understand something here. Ten years of history shows it to be effecti
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
This is simply not true! The LGPL's section 6 (the section in question) allows you to link proprietary software to a LGPL library.
Not realistically, it doesn't. Not if you define "linking" as "putting two items in the distribution package".
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.
To put it another way that hopefully illustrates how stupid that definition is:
Say I make code that calls upon an LGPL library:
- If I distribute the library and the closed code in separate installers, I don't fall under section 6, but only under section 5.
- If I create a single installer for both, then I now fall under section 6.
See the ridiculousness of this? Nothing actually changed in any code anywhere, but because I'm now packaging in one zip file instead of two, I now have to leave myself open to r
Such a work, in isolation, in unaffected (we can't tell you to change it). However, if it leaves isolation (is run in a VM) then at that point section 6 comes into play. Only at that point does it mean that either you already released in terms agreeable to section 6, or else are in violation. Distribution probably implies it will run in a VM. So at the point of distributing your code, it is no longer in isolation, but rather is for all practical points running in the VM.
you need to allow people to relink your code with new versions of the library.
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)? 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
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?
If I understand correctly, you have to allow them to link it but you don't have to garauntee that it works. If they wanna start throwing DLLs around it's their own damn problem.
I've been a little concerned about applying the LGPL to Java code for a while. Let me explain why, and perhaps you can address my concerns.
Java linking does not work in the same way as the systems that the LGPL was originally intended for (i.e. systems with static or dynamic linking in a broadly similar sense to those provided by 'ld' or 'ld.so' under Unix).
If I produce a program that uses a Java library and compile it and wrap it up in a jar file, one would usually expect that this jar file could be tre
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".
As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library
In the case of Java "import", the new work does not contain any portion of the library. Java is doing dynamic linking which is covered under section 5:
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is
It isn't easy being the parent of a six-year-old. However, it's a pretty small
price to pay for having somebody around the house who understands computers.
Yes, that David Turner (Score:5, Informative)
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.
Re:Yes, that David Turner (Score:3, Funny)
It's almost scary how non-obvious that is.
Re:Yes, that David Turner (Score:2)
I'd like to know how they arranged that!
Re:Yes, that David Turner (Score:1)
Re:Yes, that David Turner (Score:3, Funny)
Google used some GPL code right behind the button "I am feeling lucky". So the button, using the GPL code, is infexted and behave accordingly. It's a perfect illustration that the viral nature of GPL is not bad - it's rather very useful.
Re:Yes, that David Turner (Score:1)
Re:Yes, that David Turner (Score:2)
Re:Yes, that David Turner (Score:1)
Re:Yes, that David Turner (Score:2)
What a smarmy comment that serves no purpose and is absolutely irrelevant. Quite like the content of FSF licenses actually.
---
My software doesn't have a philosophy. It just works.
Re:Yes, that David Turner (Score:1)
Re:Yes, that David Turner (Score:2)
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. Similarly, people might q
Re:Yes, that David Turner (Score:4, Informative)
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.
Re:Yes, that David Turner (Score:5, Informative)
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.
Re:Yes, that David Turner (Score:3, Funny)
The LGPL isn't the GPL. If you want the GPL, you know where to find it.
Re:Yes, that David Turner (Score:1)
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.
Re:Yes, that David Turner (Score:2)
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.
Re:Yes, that David Turner (Score:1)
Sound to me like Section 6 is just reenforcing the fairness in software competition that has always existed... before the DMCA anyway.
Re:Yes, that David Turner (Score:1)
Re:Yes, that David Turner (Score:4, Informative)
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.
Re:Yes, that David Turner (Score:1)
It might be usefull to know this for other programming languaes too? maybe a nice Idea for in the faq.
Re:Yes, that David Turner (Score:5, Informative)
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:Yes, that David Turner (Score:1)
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.
4.
5. Profit!
Re:Yes, that David Turner (Score:1)
Okay, let's hash this out then... (Score:5, Insightful)
1. Create java code which uses my library (jar file) with the library as a separate jar file (ie., none of my code is in their code, they're just calling methods and classes from my code).
2. Not have any requirements placed upon their code at all in any way.
As I see it, this is exactly what the LGPL does. Section 6 never comes into play whatsoever, because their code falls into section 5. They haven't actually combined my code into theirs, it's totally separate, sitting right in that jar file (aka library).
Granted, if they modify my code and distribute the modified version, then they must distribute the modifications they made to my code as well. That's what the LGPL is for in the first place.
But I fail to see how section 6 applies in any way whatsoever. None of my LGPL'd code is included in their code in any way. It's separated because it's in a separate jar file.
Lookie here:
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
To me, this exactly describes someone calling classes or other code that resides in my jar file. They're not copying the code into their own jar, they're linking to it. But let's look at section 6:
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library...
This never happens if done properly. My jar is sitting alone, their jar is sitting alone. At runtime, their jar loads, says to the java interpreter "hey, make a class from that other jar", then my jar loads and a class gets created.
So, am I wrong here? I see no normal situation in which section 6 would ever apply to Java libraries, unless someone was straight up ripping my classes off and including them in their own jar file along with their own code.
Re:Okay, let's hash this out then... (Score:2)
Re:Okay, let's hash this out then... (Score:3, Insightful)
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.
If you use this as your definition of "linking", then "linking" loses all purpose and meaning.
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 cod
Re:Okay, let's hash this out then... (Score:2)
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.
Re:Okay, let's hash this out then... (Score:2)
I would say that that's not true. However, certainly if the two are in the same memory space, they are linked.
Define "same memory space".
On (modern) Intel-based CPUs, most OS's run in a single 32-bit memory segment. Is all code loaded into the same segment (which would be everything) now considered "linked"?
Or how about programs written for PC (or MS) DOS, where there is absolutely no memory virtualization or protection. _EVERYTHING_ lives in the same memory space -- does that make the command interp
Re:Okay, let's hash this out then... (Score:2)
Re:Okay, let's hash this out then... (Score:2)
That is nonsense. 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.
You most certainly can circumvent the LGPL by building wrappers since doing so creates a work in isolation.
If any link in memory space means that the linked programs are restricted in license then running most proprietary code on a GN
Re:Okay, let's hash this out then... (Score:2)
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.
Re:Okay, let's hash this out then... (Score:2)
You are trying spin the definition of "program" as "the sum of all parts distributed in an archive in order to make a program work, regardless of whether or not those parts can be easily obtained separately." I don't buy it. The software I've written placed into my jar is my "program". By saving the user the trouble of having to find those components and install them himself your claim that other jars in my
Re:Okay, let's hash this out then... (Score:2)
Re:Okay, let's hash this out then... (Score:2)
That's the most wacked out crazy way to look at linking I have ever heard, and if that is in fact the case, then the LGPL is severely broken and should never be used in any circumstances whatsoever, by anybody.
Furthermore, if that's the case, nobody s
Oops, revision! (Score:3, Insightful)
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.
The whole point of the LGPL is to create libraries that are open source but which can be used by closed source programs, requiring only that any modifications to the *library* be
Re:Oops, revision! (Score:2)
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 p
"hole the size of a freight train" (Score:2)
Is it really that important to you that your clients/customers be unable to discover that you used a piece of LGPL'ed code? Is it important that they be unable to discover how you used that library?
Re:"hole the size of a freight train" (Score:2)
That is, you appear to be placing great emotional weight on the idea that the user should not have the legal right to modify their copy of the bits that constitute your work.
Is it the fact that the user might change their copy what offeends you?
Or is it the second half of that sentence, that the user might while debugging discover the full details of how your software works?
Or is it
Re:"hole the size of a freight train" (Score:2)
Similarly, if I had enough woodworking skill to
Re:Oops, revision! (Score:2)
If you create a single distribution file containing both your own work and a LGPL'ed java library, then you must also provide a way for the user to replace the LGPL'ed portion with any subsequent version of that library. (where "subsequent version" means "any binary-compatible library the user has access to")
The means to do this would depend on exactly how you created the distribution file. If, as with some things we have made at work that
Re:Okay, let's hash this out then... (Score:1)
I agree that it could cause precisely that effect. The bad thing about having to distribute it in parts (or worse distribute half of it with instructions how to get the other parts) means, unless it's targetted at businesses or other techies, it ain't gonna sell. Will Joe six pack be able/willing to insta
Re:Okay, let's hash this out then... (Score:2)
Re:Okay, let's hash this out then... (Score:2)
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, and is a very big reason not to use the LGPL. It's also non-sensical, non-intuitive, and not the way that any normal person would read the document and understand it because of your wacky way to define "linking".
Re:Okay, let's hash this out then... (Score:2)
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.
Re:Okay, let's hash this out then... (Score:2)
While that's true, it's also irrelevant. What license have you seen for any major product that doesn't have "you agree not to blah, blah, reverse engineer, blah.." in it?
Such a strange definition being used for linking forces companies into Section 6, and therefore they won't be adopting open source libraries, and won't be contributing back to those libraries.
Look, guy, you can argue this all you want, but in the end, your definition of "lin
Re:Okay, let's hash this out then... (Score:2)
Re:Okay, let's hash this out then... (Score:2)
I think you're failing to understand something here. Ten years of history shows it to be effecti
Re:Okay, let's hash this out then... (Score:2)
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
Re:Okay, let's hash this out then... (Score:2)
Not realistically, it doesn't. Not if you define "linking" as "putting two items in the distribution package".
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.
To put it another way... (Score:2)
Say I make code that calls upon an LGPL library:
- If I distribute the library and the closed code in separate installers, I don't fall under section 6, but only under section 5.
- If I create a single installer for both, then I now fall under section 6.
See the ridiculousness of this? Nothing actually changed in any code anywhere, but because I'm now packaging in one zip file instead of two, I now have to leave myself open to r
Re:Okay, let's hash this out then... (Score:2)
The LGPL treats static and dynamic linking differently. Java always dynamically links.
Re:Okay, let's hash this out then... (Score:2)
Re:Okay, let's hash this out then... (Score:2)
Re:Yes, that David Turner (Score:1)
Re:Yes, that David Turner (Score:1)
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)? 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
Re:Yes, that David Turner (Score:2)
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.
Re:Yes, that David Turner (Score:1)
Re:Yes, that David Turner (Score:2)
Java linking does not work in the same way as the systems that the LGPL was originally intended for (i.e. systems with static or dynamic linking in a broadly similar sense to those provided by 'ld' or 'ld.so' under Unix).
If I produce a program that uses a Java library and compile it and wrap it up in a jar file, one would usually expect that this jar file could be tre
Re:Yes, that David Turner (Score:2)
I don't think jars for executables qualify as "library facilities".
Re:Yes, that David Turner (Score:2)
As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library
In the case of Java "import", the new work does not contain any portion of the library. Java is doing dynamic linking which is covered under section 5:
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is