Forgot your password?
typodupeerror
GNU is Not Unix Java Programming

LGPL is Viral for Java 717

Posted by CowboyNeal
from the careful-code-reuse dept.
carlfish writes "According to this post to POI-dev, Dave Turner (Mr License) of the FSF has decreed that the steps required to use an LGPL'd Java library will actually infect client code with substantial GNU-ness via Section 6 of the LGPL. (The "Lesser" GPL is supposed to protect only the Library, without infecting code using the library) This, as you might imagine, puts a few LGPL Java projects that previously thought they were embeddable without being viral in a bit of a bind. Various weblogs have further coverage." Update: 07/18 02:44 GMT by CN : The FSF's Executive Director, Brad Kuhn adds "LGPL's S. 6 allows you to make new works that link with the LGPL'ed code, and license them any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' can even be proprietary; it need not be LGPL'ed."
This discussion has been archived. No new comments can be posted.

LGPL is Viral for Java

Comments Filter:
  • by Anonymous Coward on Thursday July 17, 2003 @07:10PM (#6466384)
    they coined the term "viral" with respect to software licenses, and now everyone's using it.

    good stuff. :\

    • This viral stuff is backwards. I think the BSD license is actually more
      viral than the GPL. Here's why:

      If I decide to write a program and contribute it to free software, the
      GPL assures me that it will stay free software forever. I'd be bothered
      if somebody made it non-free, effectively stealing my work for their
      own remuneration. The GPL is effectively a vaccine against that.

      The BSD license lets people apply almost any license to my software,
      including most non-free licenses. If I wrote work under the BSD lic
      • by pstreck (558593) * on Thursday July 17, 2003 @07:30PM (#6466523)
        It all depends on which side of the coin you're looking at. Commercial software venders see the GPL'ed code as a risk to their IP. Alas, viral is a bad word to describe this any ways. Recursive licensing sounds better :)
      • by mjmalone (677326) on Thursday July 17, 2003 @07:38PM (#6466589) Homepage
        Ok, I'm not quite sure you understand what they mean by "viral" here. I think what they are saying is that code written that includes the LGPL'd Java libraries inherets the LGPL. So basically, if you include one of these libraries your code MUST be LGPL'd. This is obviously a problem.
        • They were specific that the restriction is *not* that the code would have to be LGPLed, but rather that section 6 would be in effect. Section 6 does not LGPL the code. Section 6 does place restrictions. Not the same thing. What appears relevant (besides user notification...) is "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."

          David Turner summarizes, "Section 6 of
      • by William Tanksley (1752) on Thursday July 17, 2003 @07:56PM (#6466698)
        If I decide to write a program and contribute it to free software, the GPL assures me that it will stay free software forever.

        Nope; if every copy disappears or becomes useless it's not free software (perhaps it's free, but it's arguably not software). That happens all the time with many different programs -- although by definition few of us have heard of them. (There's a LOT of them on Sourceforge right now.)

        Neither BSD nor GPL protects against that -- although the BSD license does have the possibility of attracting more users and developers due to the fact that it can be used as part of proprietary work. The only problem is that these developers can be invisible, never releasing their improvements; but that's a problem with not understanding the benefits and uses of open source.

        The BSD license lets people apply almost any license to my software, including most non-free licenses.

        Nope! It lets people apply almost any license to _derivative works_ of your work (including the trivial derivative work of simple redistribution). Your original work is yours until your copyright expires; they can't take it from you.

        Some of these pro-GPL arguments are as bad as the RIAA. "Help! They're STEALING OUR CODE!!!" At least you're not as bad as SCO: "We own all licensing rights for all derived works, but WE get to decide what's derived."

        I've thought about organizing a GPL-ed thread derived from the body of existing BSD-licensed work, just to illustrate a lesson about the BSD license. That would really piss people off, but it would be legal.

        The price of freedom is having to put up with knaves.

        Frankly, I'd be pissed if you forked my project, but it would be the needless fork that pissed me off, not the license (that doesn't apply to me because I'm BSD).

        Anyone who was pissed off would probably be so because you substituted a less freely usable license for a more free one.

        -Billy
        • "Frankly, I'd be pissed if you forked my project,"

          The only one you should be pissed on is yourself. If you chose to release your project as open source and someone forks it and you don't like it, then it's entirely your fault.
        • This is a farce (Score:3, Interesting)

          by Srin Tuar (147269)


          Anyone who was pissed off would probably be so because you substituted a less freely usable license for a more free one.

          A BSD licensed piece of code is only more freely usable from one persons point of view: the next developer.

          Once he commercializes it, it will certainly become less freely usable to the end users who ultimately receive it.

          So in the balance, BSD code is LESS freely usable than GPL. The GPL is the same free to everyone. There are tons of BSD bits that are free to almost nobody.

          Its yo

      • by JonMartin (123209) on Thursday July 17, 2003 @08:12PM (#6466811) Homepage
        This viral stuff is backwards. I think the BSD license is actually more viral than the GPL. Here's why:
        If I decide to write a program and contribute it to free software, the GPL assures me that it will stay free software forever. I'd be bothered if somebody made it non-free, effectively stealing my work for their own remuneration.

        No dumbass, they can't steal your code if it is BSD licensed. What are they going to do, break into your house and remove the source from your HD? And do the same to every person who downloaded it? Repeat after me: YOU CANNOT STEAL WHAT IS FREE. As long as someone out there has a copy of your BSD code it will always be free.

        The next point is that if someone copies your free BSD code and charges money for it they are NOT MAKING MONEY OFF OF YOUR CODE. Your code is FREE remember? They are making money off of whatever they added to your code (be it more code or a service contract or shiny packaging). If Microsoft takes your free BSD code, adds one line to it and charges $100 for it they are charging $100 for that one line of their code.

        The BSD license lets people apply almost any license to my software, including most non-free licenses. If I wrote work under the BSD license, someone could modify it and sell the result with no source code, and I'd have no recourse at all.

        Why would you want recourse? How have they wronged you? You released your code under a free license, and people are using your code. Hooray! Wasn't that the point of releasing your code?

        Anyone who wants can infect my BSD software with the non-free license virus.

        How can they "infect" your code? You still have your code sitting on your harddrive. What they have done is create an entirely new "thing" out of your code and their code.

        By the way, the BSD license allows you to apply the GPL to a modified BSD work.

        Correct. Isn't that nice and free of them?

        I've thought about organizing a GPL-ed thread derived from the body of existing BSD-licensed work, just to illustrate a lesson about the BSD license. That would really piss people off, but it would be legal.

        Perfectly legal. That's the point of the BSD license: allow as many people as possible to use the code for whatever purpose they imagine. I doubt the authors of the BSDed code would be bothered at all. They will probably be happy it is being used - that is why they released it under the BSD license.

    • by TheRaven64 (641858) on Thursday July 17, 2003 @07:27PM (#6466505) Journal
      [microsoft] coined the term "viral" with respect to software licenses, and now everyone's using it.

      Are you sure? My 1992 copy of the New Hacker's Dictionary contains a reference to the `General Public Virus', and I don't recall MS even having heard of the GPL back then...

  • GPL model (Score:3, Funny)

    by jinglecat (673072) on Thursday July 17, 2003 @07:14PM (#6466409)
    I know a way they can handle their GPL model..

    Just ask SCO!

    "If it is not OUR's then it must be Viral"

  • No problem. (Score:4, Insightful)

    by Blackknight (25168) on Thursday July 17, 2003 @07:16PM (#6466423) Homepage
    Just switch to the BSD license, like the Vorbis project did.
    • Re:No problem. (Score:5, Insightful)

      by keesh (202812) on Thursday July 17, 2003 @07:26PM (#6466490) Homepage
      I am a Java developer, and I have used the LGPL on work (and also used work that has been LGPL'ed).

      My intent in using the LGPL is pretty simple: If you want to use my library, go ahead. If you make changes to my library, those have to be released back into the wild, so the library can be improved by everyone's improvements. I'm not a 'Free Software' zealot -- I'm an open-source pragmatist.

      If the LGPL does not meet this intent with Java, then we should find or write a license that has this intent. Perhaps one of the ones at Creative Commons would work...
      • Re:No problem. (Score:3, Insightful)

        by jrockway (229604) *
        I was just about to post something like this. The spirit of the LGPL is that you can use the library for your whatever-liscensed program, but if you change the library then you show the world your changes. If Java happens to use some strange library/package/class loading system that makes the LGPL incompatible, the LGPL can be fixed.

        We should worry about intent, not physical locading of the class into memory.
      • As I understand it, the Java issue seems to be almost identical to the static linking problem.

        While I label a lot of my code as LGPL, I have absolutely no problem with static linking the code. I don't see how a few linker options are relevant to licensing of source code.

        This has always been a nitpick that has baffled me about the GPL and LGPL. Why does everyone have such an issue with static linking? Static linking doesn't change the code I release, and nor should the implementation of byte code load

    • Re:No problem. (Score:5, Insightful)

      by Michael's a Jerk! (668185) on Thursday July 17, 2003 @07:26PM (#6466494) Homepage Journal
      Perhaps you need to make an effort to understand the reasons people
      refer to the GPL as viral.

      If I spend years writing a program using no code other than my own, I
      can release it under any license I want. If I incorporate BSD licensed
      code into my program, I can still use any license I want, so long as I
      preserve copyright notices. If, however, I want to include GPLed code in
      my program, the GPL forces me to release my program under the GPL. It
      has *infected* my program. This is where the term `viral' originates
      with regard to the GPL.

      The BSD license does not affect code and cannot affect code since it
      can always be placed under another license. If someone makes proprietary
      enhancements to my BSD licensed code on his own time with his own money,
      the only code that has been infected with a non-free virus is his. My
      code is still perfectly free. I can give it to whoever I want and it
      is still as free as ever. The only thing I can't do is give away the
      other person's proprietary enhancements made with his own time and his
      own money and which could possibly completely overshadow the features
      provided by my small amount of code.

      Although the BSD license encourages the reuse of code for *any* purpose,
      including in projects released under non-free licenses like the GPL or one
      of the dozens of proprietary software licenses, doing it to piss people
      off will not get you very far, and it will make you look foolhardy,
      especially in the eyes of the people who wrote the free software (free
      for *any* purpose) that you would be making non-free. I guess you think
      no one understands the BSD license.

      All in all, a fine spirit to take in the name of free software....

    • Re:No problem. (Score:5, Insightful)

      by SuperDuG (134989) <be@ec[ ].tk ['lec' in gap]> on Thursday July 17, 2003 @07:51PM (#6466673) Homepage Journal
      I know the other comment-replies to this post have been marked -1 for one reason or the other, but in all honesty I couldn't agree with you more.

      In all honest the BSD license is the "Ultimate Opensource Freedom". You release your code in hopes of the good will of future coders seeing your code. You bank on the fact that if you had the heart to release it to the public that future developers may feel the same way. But you also realize that they may not even explore your code if it has a license that forces them to release their code.

      So corperate america is willing to take a look at the possibility if their hands aren't tied. Eventually it's the hope that they will see the benifit of the source being released in the first place and let their modifications benifit the whole as well, possibly a little later after there has been a corner on the market from the secondary developers.

      Perfect example? Macintosh OS X and FreeBSD. Apple saw that the FreeBSD system was solid and they added to it to make it a system they thought was overly viable for them and then later released an entire project (darwin) back under the BSD code it was incepted with.

      So is BSD dying? Who knows, it's a wonder what exactly BSD code is doing right now as there is no obligation for the developers to release their modifications source. It's like a behind the scenes world where everyone uses the stuff but no one admits it. But yet we still see great projects come out of it, anyone ever used OS X?

  • by oGMo (379) on Thursday July 17, 2003 @07:16PM (#6466424)

    Please read that again. And again, until you get it. The GPL is not viral. It's pretty simple, really. If you're going to use [L]GPL'd code, follow the terms of the license, or don't use it.

    You have a choice. The [L]GPL is not a little bug trying to worm its way into your code. If you chose to use GPL code, then you follow the terms, or don't use the code. It's simple.

    If you find some really neat library under the [L]GPL that you want to use, and you don't want to follow the terms, well: tough luck. Offer to compensate the author; perhaps he or she will license it to you differently. Otherwise, write your own code.

    • And again, until you get it

      Sorry, but that's like saying cholera is not bad as long as I don't catch it.

      The term "viral" pisses people like you off because it's convenient to think that it's a term invented solely for the purpose of turning people off from using it, and that's not the case. In cases like this one (and many others that I won't dredge up right now) the adjective is perfectly applicable - it implies a lack of knowledge as to how the license works and how to use it, but it doesn't make it a

      • connotation (Score:5, Insightful)

        by Kunta Kinte (323399) on Thursday July 17, 2003 @08:56PM (#6467090) Journal
        ...That's what viral means. It doesn't mean that the license in and of itself is evil or incorrect or otherwise wrong....

        I'm not a GPL fantic or anything but...

        GPL backers typically don't like the adjective "viral" to be used to describe their work because it has a negative connotation. ie. The set of associations implied by a word in addition to its literal meaning. ( dictionary.com ) To me, that position is very understandable.

        There's always more than one way to say what you mean. You can call someone "Stubborn" or you can call them "Strong willed", almost the same thing? Marketing, politicials use this type of thing very often.

        In fact 'viral', as an adjective is, I'd say, blatantly demeaning. There is absolutely nothing good about a virus, and that connotation sticks with the adjective.

        Would you tell your girlfriend "your love for her is spreading through your system like ebola"? or I love you like flies like sh**?

        Both those statements I believe express great unyeilding passion. But it may not go over that way.

      • by aug24 (38229)
        that's like saying cholera is not bad as long as I don't catch it

        Balls. [There's good logic for you ;-)]

        If you are a professional developer and you come across some neat free code that you decide to use, but you don't fully read and understand the license terms, then you are a total moron.

        To continue your analogy, that's like saying "I decided to drink the water from the river, but no-one told me that I could catch cholera". Ah, bloody diddums.

        J.

    • Please read that again. And again, until you get it. The GPL is not viral. It's pretty simple, really. If you're going to use [L]GPL'd code, follow the terms of the license, or don't use it.

      I think you missed the point. The LGPL does not do what it was designed to do and what most programmers who use it think it does with their code. That's a problem, it's not a complaint that you can't use the code for whatever you like, it's a complaint that you can't use the code in the way that the original aut

      • by oGMo (379)

        I think you missed the point. The LGPL does not do what it was designed to do and what most programmers who use it think it does with their code.

        No, the point is that calling the GPL or LGPL viral is wrong, whether or not it acts correctly in this case. Using the term "viral" is merely FUD-spreading. Saying "the LGPL has bugs when used with Java" would be far more accurate.

        Besides, my point stands: you're responsible for knowing the actual terms of the license, not just thinking you know what it m

    • Nonsense. The GPL is intended to do exactly what you say it doesn't: it's intended to make all software free. It's a tool intended to destroy copyright from within.

      Saying that it's viral is mere shorthand for that, and you obviously know that (since you define viral in that way).

      Now, your prescription to deal with the viralness is quite on-target -- money talks, and coding your own dang solution also works. But this doesn't change the facts about how the GPL works, and how it's intended to work.

      Grin... T
      • by alienw (585907) <alienw DOT slashdot AT gmail DOT com> on Thursday July 17, 2003 @07:54PM (#6466689)
        What are you smoking? I want some of that.

        The GPL is a tool to make YOUR software free, not someone else's software. It's not designed to "destroy copyright from within". If you think so, you are a retarded assmonkey who needs to shut up and read what Richard Stallman has to say about the goals of the FSF and the GPL.

        Unlike certain EULAs and NDAs, the GPL is not viral. Looking at GPL'd code is permitted, no strings attached. You just can't copy GPL-licensed code into your program unless it's also GPL-licensed. I don't see how this is viral.
        • Before you go calling people names, you might want to find out what it is you're talking about.

          1. The GPL does not prevent you from copying GPL'd code into a non-GPL'd program. You are completely free to do that. The GPL prevents you from distributing that code as part of a non-GPL'd program. A company, for example, could create their own proprietary software based in part on GPL'd code and distribute it throughout, but not outside of, the organization.

          2. Like it or not, viral is not an unreasonable
        • by Minna Kirai (624281) on Friday July 18, 2003 @01:13PM (#6472066)
          The GPL is a tool to make YOUR software free, not someone else's software. It's not designed to "destroy copyright from within". If you think so, you are a retarded assmonkey who needs to shut up and read what Richard Stallman has to say about the goals of the FSF and the GPL.

          It is intended to make all software free. That is the goal of the FSF and the GPL. Eric Raymond of the Open Source Initiative takes a more moderate view, and explains that some categories of software should not be free... but that's not the GPL's goal.

          By use of the GPL, RMS hoped to make all software Free by providing quality GPL code as an incentive for new programs to be GPLed too. Otherwise, they'd be missing out on many cheaply available features. The idea was that GPL use would snowball- at some point, when the preponderance of useful libraries are GPLed, then creating a non-GPL program that can't use them would be an exercise in futile money-wasting.

          RMS doesn't like the LGPL [gnu.org] for this reason- he does not want people to be able to link to Free libraries without Freeing up their code. That's why he renamed it from "Library GPL" to "Lesser GPL"- to emphasize disapproval.

          The word "viral" to describe the GPL is of course incorrect- unless one also agrees that the copyright system is viral itself (according to the legal definition of a derived work, which are "infected" with the copyright of the previous author).
      • by oGMo (379)

        Nonsense. The GPL is intended to do exactly what you say it doesn't: it's intended to make all software free. It's a tool intended to destroy copyright from within.

        Yes, basically, and no, I didn't say it wasn't.

        Saying that it's viral is mere shorthand for that, and you obviously know that (since you define viral in that way).

        Precisely wrong. The idea is to provide a great deal of high-quality software that's Free(tm) such that's it's easier (and perhaps cheaper) just to write more Free(tm) so

      • by WatertonMan (550706) on Thursday July 17, 2003 @07:59PM (#6466721)
        It's a tool intended to destroy copyright from within.

        Your complaints against the word "viral" would hold a lot more if you didn't then go and describe the GPL using language that describes how viruses work and kill things. . .

        Yeah, unintentional, I know. But that's why people use the word "viral." It is these subtle things most people aren't that familiar with that makes GPL so insidious. Perhaps Slashdot readers are familiar with the endless debates over GPL. However not everyone is. When some manager finds these things out.

        I agree with those who say it is the users duty to read the license restrictions. But realize that those who then reject GPL software likely are doing it because they don't want this "anti-copyright" virus. If some do and see some benefit from the virus, more power to them. Lots of things that are negative to some are positive to others.

        The virus metaphor is so apt because what uses the GPL code is "contaminated" in a way that most libraries don't do. I'm all for open software, but prefer licenses like BSD's which doesn't have these hidden anti-capitalist or anti-copyright policies.

      • Nonsense. The GPL is intended to do exactly what you say it doesn't: it's intended to make all software free. It's a tool intended to destroy copyright from within.

        BS. The GPL is intended to force a give some take some trade agreement on people who use free software. If you want to make your job easier by using somebody else's code, then the GPL forces you to do a favor in turn by making your code available to make somebody else's job easier (if you want to distribute it, that is).

        It is not intended to
      • by fanatic (86657) on Thursday July 17, 2003 @08:51PM (#6467056)

        The GPL is intended to do exactly what you say it doesn't: it's intended to make all software free. It's a tool intended to destroy copyright from within.

        That's right. GPL'd code reaches up, grabs you by the throat and makes you insert it into your project.

        Oh, you mean it doesn't?

        Then, it must, by itself, open your code in your favorite editor, and type itself into your code?

        Oh, it doesn't?

        Gee then you must be a fucking dumbshit, since your code got the GPL-ness in it because you included GPL code in your code. Because that's the only way it can happen.

        CHrist, how many times does it have to be said? If you don't wnat your code GPL'd, don't use GPL'd code in your code. Even a moron like you should be able to undestand that.

        Now this issue of using the LPGL .jars, it looks to me like you escape your whole work being LGPL' if you "b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with." So, if you dind't actually incorporate the libraries into your code, ocne again you are OK.

    • by IntelliTubbie (29947) on Thursday July 17, 2003 @07:34PM (#6466553)
      You have a choice. The [L]GPL is not a little bug trying to worm its way into your code. If you chose to use GPL code, then you follow the terms, or don't use the code. It's simple.

      You seem to miss the entire point of the LGPL. The whole point is that you should be able to use LGPL code in a non-LGPL project. To quote from the website [gnu.org]:

      "The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs."

      So whereas the GPL is intended to be somewhat "viral" -- i.e. software using GPL code must also be GPL -- the LGPL is not supposed to. This is why the viral-ness of the LGPL is news, since it's contrary to much of the community's understanding and intent regarding the use of LGPL code.

      Cheers,
      IT
    • I have to agree (Score:2, Insightful)

      by abe ferlman (205607)
      This is an interesting topic, but the way the submitter phrases it is 100% pure flamebait.

      The GPL (and to a lesser extent the LGPL) is a vaccine for the body of free code (a little bit of benign IP law to save us from the ravages of truly malignant IP law), not a disease you catch accidentally.
    • by p3d0 (42270)
      Have we hit your pet peeve here?

      Obviously if you don't use GPL'ed code, then you have no problem. Equally obviously, then, that can't be what people are talking about when they say it's viral.

      The GPL has the property that, if you derive a project from code covered by it, your own code must also be covered by it. Most licenses don't have that property. So, if your 10,000 LOC project has 50 LOC covered by the GPL, you must license the whole thing under the GPL (in which case the GPL has effectively tra

  • It's worth pointing out that no-one (except a court) is really in a position to 'decree' what the LGPL clause 6 means if it really is a close call on more than one interpretation. If it turns out to be ambiguous or contentious, the best move could be to debate a clarification and campaign for the adoption of that instead.
  • by bokmann (323771) on Thursday July 17, 2003 @07:21PM (#6466453) Homepage
    I am a Java developer, and I have used the LGPL on work (and also used work that HAS been LGPLed).

    My intent in using the LGPL is pretty simple: If you want to use my library, go ahead. If you make CHANGES to my library, those have to be released back into the wild, so the library can be improved by everyone's improvements. I'm not a 'Free Software' zealot - I'm an open-source pragmatist.

    If the LGPL does not meet this intent with Java, then we should find or write a license that has this intent. Perhaps one of the ones at Creative Commons would work...
    • by sterno (16320) on Thursday July 17, 2003 @07:34PM (#6466554) Homepage
      The problem here is that the technicality of this section of the LGPL and the FSF's interpretation of it are not in sync with 98% of the people using and releasing code under the LGPL. I've used LGPL code and seeing as the jars were libraries it didn't even occurr to me that this would be an issue.

      This causes uncertainty over the nature of LGPL software right now. Would a court of law agree with this interpretation? Now I'm left with an odd decision. Do I gut my code under the presumption that this FSF lawyer is right, or do I take my chances that a court will interpret this as the vast majority of the community has.

      Open source software lives by the certainty of the licensing it uses. If we can't trust the interpretation of the licenses, then we can't feel confident in working with this code. The FSF is risking a serious blow to the open source community.
      • The apache interpretation has always been: every java app is a jar', so every app is a library, so for java, LGPL has the same semantics as GPL.

        We now have official confirmation that this is the case, even if that is not what people who released LGPL java code intended. Maybe those people need to rerelease their code as GPL to formalise the outcome.

        The effective result is that Apache Java projects are forbidden from linking to LGPL libraries, so we either go without the code or reimplement it -a loss eith
      • Open source software lives by the certainty of the licensing it uses. If we can't trust the interpretation of the licenses, then we can't feel confident in working with this code. The FSF is risking a serious blow to the open source community.

        So why not just draft your own license that's basically the LGPL, except that it is built specifically so that it will work as most people expect it to with Java libraries (and maybe other languages, like Objective-C libraries)?

        Make sure that the license is c
  • by Anonymous Coward on Thursday July 17, 2003 @07:23PM (#6466467)
    The post states that you cannot import or "lift" any lgpl code * code * code into another project unless that project becomes lgpl'd also. This is correct; however, the resulting lgpl'd library (binary) can be called / used by a non-lgpl'd project. It is really not that confusing.
    • The post states that you cannot import or "lift" any lgpl code * code * code into another project unless that project becomes lgpl'd also. This is correct; however, the resulting lgpl'd library (binary) can be called / used by a non-lgpl'd project. It is really not that confusing.

      You are absolutely wrong. What they are really saying is that the LGPL works virtually the same as the GPL when it comes to Java code because Java code doesn't use early linking, everything is bound at runtime, thus there is n

      • by bwt (68845) on Thursday July 17, 2003 @08:58PM (#6467103) Homepage
        But there is a clear distinction. The LGPL library is loaded from one jar on the classpath at runtime and the rest of the code is loaded from somewhere else. They're clearly separable. If you modify anything in the LGPL jar (or class) and distribute it, you must include full source to everything packaged in that jar, but if you don't do that you are fine, even if you're dealing with full GPL java code.

        The JVM plays the same role as bash does: it loads separately packaged programs into memory, and handles messages being sent back and forth, none of which implicates any right held by the copyright holder of either. I my propietary class calls your GPL'd or LGPL'd class, so what!? How is that different than my proprietary bash script calling grep? As long as I don't modify or distribute your code, or copy parts of it into mine, I don't need a licence.

        If you say the method calls are me copying your code, I'll argue back that public method names are a fair use for interoperability.
      • Turner explained himself further in subsequent posts. You simply need to follow the rules for LGPL in Java as in C (ie, package your app so that the LGPL library can be replaced simply). You state that:
        the LGPL works virtually the same as the GPL for Java code.
        Certainly you can use the LGPL for C. Therefore, what is in fact true is that
        the LGPL works virtually the same for Java as for C.
      • The only comment from "the FSF-license guy" in he linked article is:

        This sort of linking falls under section 6 of the LGPL.

        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, and 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

        Someone has misin

  • obWhore (Score:3, Insightful)

    by dspeyer (531333) <dspeyer@@@wam...umd...edu> on Thursday July 17, 2003 @07:24PM (#6466473) Homepage Journal
    The site's awfully slow already; I suspect it's going down soon, so here's the content:

    Subject: Re: [Followup] RE: Possibly Include HTMLParser Jar in contribcode?
    From: "Andrew C. Oliver" <acoliver <at> apache.org>
    Date: Wed, 16 Jul 2003 08:12:12 -0400
    Newsgroups: gmane.comp.jakarta.poi.devel

    You cannot. Though the FSF has stated that the Apache interpretation was correct and that importing classes from LGPL jar files in Java does indeed cause the "viral clause" to apply to Java.

    Please stop saying "lift the code" or other things that imply violating the copyright.

    Under no circumstances can any LGPL code be used as it would require us to LGPL our code per section 6 of the LGPL license and the statement I received from the Free Software Foundation's Dave Turner (the man behind licensing <at> fsf.org):

    " Me:

    Brett Smith referred me to you regarding a question regarding the Lesser Gnu Public License (LGPL) in regards to Java. It is the interpretation of most of the open/free software communities that the use of a "jar" file by a piece of software linked via a Java "import" statement does not bind the linking work under the terms of the LGPL. The Apache Software Foundation, presently takes a more conservative view and thus projects of the ASF are not allowed to link/distribute LGPL programs into Java projects of the foundation.
    DT: This sort of linking falls under section 6 of the LGPL. "

    In short, Sam was right, I was wrong.

    -Andy

    On 7/16/03 4:55 AM, "EPugh <at> upstate.com" <EPugh <at> upstate.com> wrote:

    Sorry I haven't been on the list more, been traveling the last week. At any rate, Andy, did you ever get a resolution to including the HTMLParser Jar?

    Should I just submit a code change the mimics the code that I need from HTMLParser, I mean, it is just a long list of values being populated into a Map! That is all I really want, versus sophisticated translation of character set logic or something...

    Thanks for your efforts... eric

    --
    Andrew C. Oliver
    http://www.superlinksoftware.com/poi.jsp
    Custom enhancements and Commercial Implementation for Jakarta POI

    http://jakarta.apache.org/poi
    For Java and Excel, Got POI?


  • Viral? Infected? (Score:3, Interesting)

    by foolip (588195) on Thursday July 17, 2003 @07:27PM (#6466503) Homepage
    Please, why do we need to hear these words in relation to the (L)GPL? Apart from the fact that they have a very negative tone, they don't even properly describe the nature of the GPL.

    There are few ways you could _accidently_ end up in a situation where your code is in violation of the GPL (i.e. a situation where you are required to release your code under the GPL or remove GPLd parts of it). Of course, if you don't know what you're doing you could use for example GNU readline for your program and not discover until the end of development that you are required to distribute your program (a derivative work in legal code) under the terms of the GPL, but since when does negligence make something viral?

    If something were viral, you could end up "catching" it even if you didn't want to, but the only way to get yourself into a situation where your code must be distributed under the GPL is if you want that to happen, or if you don't bother checking the terms of use+distribution of the software you're using.

    A better word might be "self-propagating". Technically it is of course developers using GPLd code who propagate the license, but that's just semantics.

    As you know, there are _no_ restrictions of using GPLd software, so there's no risk of "infection" there.

    [end rant mode]

    I'm not saying here that everyone who doesn't understand the GPL is an idiot and deserves to have their code affected, only that viral is an inappropriate word.

    As for the LGPL+Java thing, well my post has nothing to do with it :)
  • I get a couple requests to use the Lesser Gnu Public License for my Java utilities [ostermiller.org] a week. I say, "I use the GPL to encourage open source development. If I were to use the LGPL, then you could use my libraries without giving me the source to your program.".

    If you are really serious about free software. Then you will never use the LGPL [gnu.org].


    • If I were to use the LGPL, then you could use my libraries without giving me the source to your program.".

      but if the other person made improvements or bug fixes to your LGPL code, then he would (have to) share those changes with you. You benefit.
    • I say, "I use the GPL to encourage open source development. If I were to use the LGPL, then you could use my libraries without giving me the source to your program.".

      They still can -- the GPL only requires a party to provide their changes to your code _if_ they redistribute the code. And then, they only have to provide it to the people they redistribute the binaries to.

      You may never see their changes if they don't redistribute your code, or if they decide to redistribute it only to those people they've

  • by adamy (78406) on Thursday July 17, 2003 @07:28PM (#6466510) Homepage Journal

    b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

    So what you should do as a LGPL library developer is:

    1. Define interfaces for all the objects.
    2. But these into their own Jar files. Tag these as the interface.
    3. Both the Implementing Jar and the calling program refer to eah other through the interfaces only. Somewhere in the interface Jar is a Factory the various implementations can regster themselve with to provide dynamic loading.

    This is how Databse and Cryptography stuff works in Java. If it can't be done this way, it is probably not a library.

    Note that doing:

    List l = new LGPLList(); is probably Illegal but

    List l = (List) Class.forName("org.gnu.LGPLList").newINstance();

    Is probably OK. Note that I say probably. I'm not a lawyer, nor do I play one on TV.
    • by bwt (68845) on Thursday July 17, 2003 @08:38PM (#6466989) Homepage
      I'm really baffled by what the issue is. It appears to me that the LGPL works just fine for Java.

      Suppose I write a libarary in Java and place it under the LGPL. I also create a jar file for it. You write some code which uses my library and includes some import statements that name a package in my jar. You compile your stuff into a separate package jar. You distribute your jar which contains none of my code source or bytecode other than calls to public methods. I don't see any reason to think the LGPL places any requirements on your jar.

      Java's built in class loader seems ideal as a "suitable shared library mechanism". So long as the LGPL library is on the classpath, it will get loaded at run time, as modified or not, and it will work so long as the public method signitures don't change. This is what the LGPL means when it uses "interface" -- it is NOT talking about a declared interface in the Java sense, but simply the public method calls treated as an API.

      The difference between the standard contstructor form and the Class.forName form seems like a distinction without a difference to me. Both use whatever library class is on the classpath at runtime and don't depend on it being unmodified aside from the method signatures.

      I'm baffled by this article and the claim that the LGPL is problematic in Java. It seems to me that so long as you distribute your code which uses an LGPL class or jar without including your own copy of that LGPL libary, you are fine. Heck, you could even distribute the LGPL library as long as you do it in a separate download.

      In fact, I would go one further. Even if the class you are using was full GPL, how does my program care so long as I don't distribute your code? Because of OO encapsilation, my code does not depend on anything other than the public methods I call, and I'm not sure an API can be copyrighted, or if it can that interoperability is not a fair use. What right of yours would I be violating? I'm not distributing a derivitive of your code (unless you think like SCO), nor modifying it. The only thing that I copy is API call signatures. So what?

  • So does that mean if I have a Perl or Python module under the LGPL that is used/imported into a project, the LGPL applies?
  • by carlfish (7229) <cmiller@pastiche.org> on Thursday July 17, 2003 @07:30PM (#6466524) Homepage Journal
    The general "nerd on the street" understanding of the LGPL is that so long as you don't make any changes to an LGPL Library, then making use of that library doesn't place your own code under any further obligation.

    Section 6 contradicts that understanding. However, Java programmers have generally believed that Section 6 does not apply to them, because Java is a late-binding language. The LGPL talks about "linking executables", but Java doesn't perform the linking step until runtime, supposedly freeing Java of the Section 6 responsibilities to give an offer (valid for three years) to distribute the LGPL'd library source themselves, plus anything you would need to make the app work with a modified version of the library.

    The advice that Section 6 actually _Does_ apply to late-binding languages places a significant burden on projects making use of LGPL'd libraries that until now they didn't think they had to meet.
  • Their is no information to support this claim, so the article and all the linked blogs are worthless.

    Please repost when your article and or references actually contain information worthy of discussion.

    I use LGPL on some of my java code. Why ClassForName is supposed to be special I have no idea. I am lost here. a jar file is no different in usage from a DLL, so their really needs to be some support of these ideas...
  • Viral... (Score:2, Funny)

    by en4ca (543233)
    Did anyone else read this as LGPL is Vital for Java. Guess thats what happens when you're half asleep
  • I'm not sure I understand the issue. Does Java's "import" statement incorporate any of the library's copyrighted content into the program being distributed? If it doesn't then my opinion is that the LGPL should NOT apply unless the LGPL'd library itself is distributed along with the program. If the library is distributed with the program, or if the program contains a portion of the LGPL library, then of course it should be treated like linking any program to an LGPL library.

  • by reynaert (264437) on Thursday July 17, 2003 @07:36PM (#6466572)
    The FSF's interpretation of the LGPL only applies to software owned by the FSF. If I had a different interpretation of the LGPL (which is certainly possible -- many parts are quite vague), that interpretation would apply to my software, and the FSF can do nothing about it.

    One example of one such non-standard interpretation is the "Lisp LGPL", used by Franz [franz.com] for their open source libraries. Parts of the LGPL don't make much sense for non-C-like languages such as Common Lisp, so they added a preample [franz.com] which explains their interpretation.

    Another real-world example is Pine. Early versions of Pine had a BSD-like license, which allows "modification and distribution". The University of Waterloo interpreted this to mean that you could modify Pine, or distribute an unmodified Pine, but not distribute a modified Pine. This was contrary to everybody else's interpretation, but they owned the copyright so they got to decide. (More recent versions have a different license).

    • Has the GPL or the LGPL ever been litigated? With the opportunity for interpretation being what it is, you would think someone would push the envelope and wind up in court. Have they?
    • by ajs (35943) <ajs@@@ajs...com> on Thursday July 17, 2003 @09:09PM (#6467152) Homepage Journal
      There's a flaw in your logic. You cannot retro-actively interpret a license. The license is an agreement. If you then decide that the agreement "really means" something other than what I think it means, we have a dispute. We can settle it between us by altering the agreement to be clear on the point, or either one of us can take the matter to court for resolution. This happens all the time. What you meant for the agreement to say is beside the point unless we had some form of verbal or implied understanding at the time.

      If, for example, SCO got to tell IBM, "well, our interpretation of the license for UNIX means that you can't put code from Sequent into Linux," then IBM would be quite unhappy about the results.

      I think the point of confusion here is history. Long ago, Linus made a big splash when he stated his interpretation of the GPL for purposes of binary-only drivers. A lot of folks walked away from that assuming that that meant he had the ability to retro-actively interpret ambiguity in the GPL.

      That was not at all the case. What Linus was doing was essentially making a promise to holders of this ambiguous license (and the GPL *is* ambiguous on that point, IMHO) that he was interpreting the license in the most liberal possible way, and thus no one need fear that he would sue them over it.

      He could still sue, of course, but his public statements would weigh heavily against the outcome (the scary part for businesses is that you still run into litigation risk regardless of the fact that the cards are stacked in your favor).

      On the other hand, if Linus had said, "I'm interpreting the GPL to mean that you can't link your binary-only driver into Linux without creating a derived work which may only be distributed under the terms of the GPL," then the ambiguity would still remain, and no one would be sure if Linus was right or wrong about that until precident was set in court (which it probably has in other contexts outside of the GPL, but I'm not at all sure about that).

      The same thing happens if I say, "I interpret the GPL to mean that you [can/cannot] distribute my software on DVD media." My interpretation is just that, and does not affect you at all. You might, of course, think to yourself, "hmm... this guy is interpretting the GPL in exactly the same way a first-class nut-case would... perhaps I should use some other software."

      That's fine, you can feel that way, and I would not blame you in the slightest. But that social dynamic does not change the essence of the GPL, nor our agreement as stated in the GPL.
  • Because of the way copyright laws work, and the GPL (and LGPL) only cover distribution...

    Once a user has the code, they can do whatever they want with it, right? So, you can distribute your java code, and it will try to import the library, and they can go get the library, and it will work, right? Even with GPL code... You don't have to have the source for it to work. How can their license affect what you have to do?

  • Not his call (Score:4, Insightful)

    by Otter (3800) on Thursday July 17, 2003 @07:39PM (#6466597) Journal
    Dave Turner (Mr License) of the FSF has decreed that the steps required to use an LGPL'd Java library will actually infect client code with substantial GNU-ness via Section 6 of the LGPL.

    We get statements like that all the time from the FSF and there's no validity to them.

    The FSF writes their licenses. Any subsequent ambiguities are to be decided in court. There is no basis for post-facto "decrees" about what a document is supposed to mean -- the author has the opportunity to write it to cover whatever case, and has the responsibility to make his intentions clear then.

  • What about languages like PHP where the application is never compiled? The only way to use someone else's PHP is to #include it into your application - merge the code into your application.

    Seems to me like the [L]GPL is sorely lacking in many areas - I'm developing a library and application in it, and it's very confusing to me to have to understand how to combine code that is not mine with code that is, without violating the license. I can't possibly write everything myself, and I want to be able to collaborate with other people... but any code of mine that is LGPL, can only be used in LGPL applications, and any code of mine that is GPL can only be used in GPL applications. And if my friend wrote a function that is GPL, I can't use it in my LGPL library without making it GPL, even if he wants me to! (He has to relicense his code under the LGPL for me if I actually am going to use it!)

    I don't know if that's Viral or not, but it sure sucks.
  • Misleading article (Score:5, Informative)

    by timsuth (466108) on Thursday July 17, 2003 @07:43PM (#6466616)
    This slashdot article is misleading. It gives the impression that if your Java code uses an LGPL library then you must provide your source code, permit changes/redistribution etc.

    This is not the case. What the FSF guy way saying is "With respect to the LGPL, 'import' in Java is equivalent to linking in C." This means that if you make changes to an LGPL library you use via import in Java, you must make the changes to the LGPL library available to others. This is exactly the same situation which applies in the C world.

    The reason the Apache people don't want to use the LGPL (for any language) is that they want their libraries to be under a more permissive license which allows the libraries to be modified without requiring the users to make the changes available.

    Some people were suggesting that there was a loophole in the LGPL which meant that they could 'import' a library in Java and avoid having to make changes to the LGPL library available.

    The "news" is that the loophole does not exist - the LGPL applies to Java in the same way as it does in C.
    • by AKAImBatman (238306) <akaimbatman@gmai[ ]om ['l.c' in gap]> on Thursday July 17, 2003 @08:20PM (#6466859) Homepage Journal
      I said it before and I'll say it again: The "import" statement is a language construct ONLY. No actual linking is done by using it.

      Check my history for the last message I posted on this.
      • by CustomDesigned (250089) on Thursday July 17, 2003 @11:12PM (#6467857) Homepage Journal
        The 'import' statement in Java doesn't actually link anything - it is just a namespace declaration. However, when you refer at compile time to methods, fields, and constants in another class, the compiler actually reads in that class and does the equivalent of '#include done right'. This makes Java code that directly refers at compile time to LGPL code a derivative work.

        However, you can use a plugin model to use an LGPL library without directly importing it. You write an interface that your code imports, and write an implementation that imports both your interface and the LGPL library. The implementation of your plugin interface is now LGPL, inherited from the LGPL library. However, your code that that simply imports the interface is not LGPL.

        If you are wondering how the implementation class every gets instantiated without refering to it at compile time, then you are not an experienced Java programmer :-) The answer is that your factory class reads a config file to get the name of the implementation class, and then loads it via Class.forName() (or one of the more complex ClassLoader APIs).

        Now, your application has avoided becoming LGPL (except for the small class that implements the plugin API). Furthermore, you are conforming to the spirit of the LGPL because users of your application can easily adapt any future version of the LGPL library - or even their own innovation implementation - using your plugin API, and the working source you provide to 'plugin' the LGPL library.

        For illustration, suppose there is an LGPL library to translate any text from one language to another. It provides a Translator class (sorry, Slashdot doesn't seem to let me indent the code):

        /* LGPL license */
        package fsf.goodies;
        import java.util.Locale;
        public class C3P0 {
        public String translate(String msg,Locale src,Locale dst) {
        /* magic AI code here */
        }
        }
        Now, you want to use this in your BSD license UberChat application. You can't just use Translator, because then your app would need to be LGPL as well. Instead, you define an interface:
        /* BSD license */
        package org.bsd.uberchat;

        import java.util.Locale;

        public interface Translator {
        String translate(String msg,Locale src,Locale dst);
        }
        Then, you make a plugin that implements the Translator interface. Your plug in is LGPL because it uses the LGPL library.
        /* LGPL */
        import fsf.goodies.C3P0;
        public class C3P0Plugin implements Translator {
        /* in this trivial example (except for C3P0, that is), nothing more is required. In real life, you might need to massage arguments and do other processsing to match the interface with the implementation. */
        }
        Finally, you need a factory class to obtain a Translator instance:
        package org.bsd.uberchat;

        public class TranslatorFactory {
        /* Actually, there are more exceptions that needs to be handled in a real factory class. */
        static public Translator getTranslator() {
        Config config = new Config("uberchat");
        String cname = config.getString("translator");
        Object trans = Class.forName(cname);
        if (trans instanceof Translator)
        return (Translator)trans;
        throw new RuntimeException("translator plugin does not implement the proper interface");
        }
        }
        Finally, using the plugin is simple:
        package org.bsd.uberchat;
        import java.util.Locale;

        public class Foo {
        static public void main(String[] argv) {
        Translator t = TranslatorFactory.getTranslator();
        String msg = t.translate(argv[0],Locale.US,Local.GERMAN);
        &nbs p; System.out.println(msg);
        }
        }
        And, while none of this is tested, presumably with "fsf.goodies.C3P0" as the value of the "translator" property in your configuration framework (now included with Java 1.4), running
        java org.bsd.Foo "Good Day!"
        should result in an output of:
        Guten Tag!
        • by jemfinch (94833)

          Now, you want to use this in your BSD license UberChat application. You can't just use Translator, because then your app would need to be LGPL as well.

          This is where you're wrong. You can always link (2-clause) BSD licensed code with code of any other license, including the (L)GPL, without relicensing the BSD code. It's not like you link with the (L)GPL and suddenly your code is required to be less free -- your code can be released under whatever freer than the (L)GPL license you prefer, and linking wi

    • Because Java makes such extensive use of OOP priciples, it would be possible to "rewrite" entire libraries by operator overloading the entire class. You'd be changing their libraries but claim you're not technically breaking the rules of LGPL. The FSF says you need to maintain a clear distinction between the seperate file. You should be able to drop-in-replace any newer version...again, if you're following the rules then you're OK. This really only applies to a small number of rules lawyers attempting
  • by prizog (42097) <novalis-slashdot@@@novalis...org> on Thursday July 17, 2003 @07:50PM (#6466666) Homepage
    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.
    • you can find our phone number on our web page by searching for "s" on Google and clicking "I Feel Lucky."


      It's almost scary how non-obvious that is.
    • by Otto (17870) on Thursday July 17, 2003 @10:21PM (#6467513) Homepage Journal
      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.
  • Bunch of Crap! (Score:5, Informative)

    by OYAHHH (322809) on Thursday July 17, 2003 @08:02PM (#6466736) Homepage
    This material should be considered akin to shouting fire in a crowded theatre when there isn't a spark around for miles.

    Anybody who works regularly with Java will understand the mechanics of how professionals work with provided libraries and that those same mechanisms fit perfectly with the requirements of Section 6, Part B of the LGPL.

    It's pretty obvious that the writer doesn't understand Java programming or Java systems configuration.

    To explain how Java works, basically if you want to utilize a third party library all you need to do is:

    1. Distribute Sun's (or a suitable facimile) Java Runtime Environment to your target clients.

    Note that the standard JRE comes with a ../lib/ext directory just for the explicit purpose of dropping in your libraries and any third party libraries.

    BTW, once in the ../lib/ext directory the library is effectively shared for any Java program utilizing this particular JRE installation.

    2. Put your own libraries in the ../lib/ext directory.

    3. Put the third party library in the ../lib/ext directory.

    4. Run your Java program. Note how long it takes to "load up".

    My guess is that one of the things the JRE is doing is reading those libraries to "know what it has available" and storing that info in some sort of a hashtable.

    5. During your program's execution create a object from the third party library.

    Note, that the Java interpreter merely looks up the class in the hash via an internal call that anybody can duplicate. But why when all you are duplicating what is already built-in the Java interpreter.

    If some client/end-user wants to substitute in a modified version of the third party library then there is nothing stopping them.

    They can drop in a modified or a substitute library just so long as the class names and method names, etc.. stay the same.

    Whether the program continues to work is a totally different matter.

    But the key point is is that the entire process is all dynamic. And from one run of the program to another run nothing guarantees the calling program that the third party library is actually the one that was originally installed.

  • Please, people (Score:5, Informative)

    by Fnkmaster (89084) on Thursday July 17, 2003 @08:06PM (#6466763)
    Go back and read the LGPL again. The terms in Section 5/6 are not the terms commonly used with Java, sure, but the intent is pretty much crystal clear. If you use material from header files (read: interfaces or general class descriptions - the stuff that goes in header files in the C world) to make calls into the classes falls outside the scope of the license. The LGPL is no more or less befuddling with respect to Java then it is with respect to other languages. Likewise, the relationship elucidated between your object code and the LGPLed object code, whether it be in JAR or DLL format, isn't terribly different. If you contain or reuse too much of a library in your code, there's always a fuzzy, slippery slope of what constitutes a derived work. Again, this is really no different from the way the LPGL would apply to C/C++.


    So Section 5 applies just as it does with non-Java code. Likewise, Section 6 is pretty darned clear. Section 6b still applied for Java - Java runtime linking meets all the requirements of 6b. What's the big deal? As long as the LGPLed library (or it's "modified form" you distribute under your own terms, per section 6) is distributed in a separate JAR, it can be replaced by another, recompiled version of the JAR. You can change one line of code, and recompile the original library to a JAR file, distribute it under your own terms, just provide source for your "modified" version of the library, and you have complied with section 6. Voila. There's no need to jump through these hoops though, section 5 still applies, let's not get our panties in a bunch, the sky has not fallen.

  • by p3d0 (42270) on Thursday July 17, 2003 @09:31PM (#6467253)
    I quote Mr Turner's statement in its entirety:
    DT: This sort of linking falls under section 6 of the LGPL.
    He does not answer in the affirmative, nor in the negative. He merely points at section 6. He does not even offer any interpretation.

    How could this be construed as saying that "LGPL is Viral for Java"?

    Maybe there's more to it in that one link that's Slashdotted.

  • by bkuhn (41121) on Thursday July 17, 2003 @10:27PM (#6467558) Homepage

    LGPL's Section 6 allows you to make new works that link with the LGPL'ed code, and license those new works any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' (as mentioned in the story posting) can even be proprietary; it need not be LGPL'ed. LGPL's Section 6 does place some requirements on what you do, but that is only to make sure that people can effectively exercise their freedoms to copy, modify, and redistribute the LGPL'ed code.

    -- Bradley M. Kuhn, Executive Director, Free Software Foundation

    • I think the issue is that in java you can use OOP to overload all the classes in a LGPL lib to do your own bidding. Then you can wrap up that LGPL .jar in another .jar for your project. At that point you've effectively rewritten the lib but are trying to bury the evidence in your .jar bytecode file. All the FSF is saying is that you can't bury stuff like that...you have to use proper calls--or make darn sure your overloading is version independant! You have to keep the LGPL .jar seperate from the rest o

"A mind is a terrible thing to have leaking out your ears." -- The League of Sadistic Telepaths

Working...