Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: licensing ... [Re: binary XML API and scientificuse ca
 that should get all this clarified: http://www.gnu.org/licenses/lgpl-java.html so finally there is one official FSF link to refer when discussing java and LGPL. alek Stephen D. Williams wrote: > I think that I'm pretty clear on GPL/LGPL; I've been part of these > kinds of discussions for a very long time, since the posting of the > first GPL. I actually used both commercial Emacs products (CCA and > Unipress I think they were called) at work at GE Lighting in 1985; > products that caused Richard to write GNU Emacs and the GPL 1.0. I've > also imported GPL/LGPL software into several large companies over the > years so I jump into this discussion out of long habit. > > You are right that the one question asked specifically about Java and > GPL, which was probably an oversight by the questioner. The last > sentence of Eben's answer however makes it clear that LGPL+Java > wouldn't be a problem. His answer on LGPL was: "If the author of the > other code had chosen to release his JAR under the Lesser GPL, your > contribution to the combined work could be released under any license > of your choosing." > > sdw > > Cutler, Roger (RogerCutler) wrote: > >> I believe that there is some confusion here between GPL and LGPL. Or at >> least if you folks aren't confused you are confusing me, and by >> extension possibly others. Note that the notes below differ in which >> one they refer to, and some of the links in other postings have, I >> believe, been to discussions of GPL whereas the initial question was, I >> think, about LGPL. As I understand it GPL and LGPL are different, and >> LGPL is weaker than GPL. See, for example, >> http://www.opensource.org/licenses/lgpl-license.php, which I beieve is >> the "authoritative source" on LGPL somebody was asking for earlier. >> >> Just speaking personally, LGPL may be weaker than GPL, but I read the >> document referenced above and I must confess that I still find it a bit >> scary. I do understand that many people are comfortable with these >> licenses, but I think it's really a good idea to understand them clearly >> if you are going to have anything to do with software using them. >> >> -----Original Message----- >> From: public-xml-binary-request@w... >> [mailto:public-xml-binary-request@w...] On Behalf Of Stephen D. >> Williams >> Sent: Monday, November 22, 2004 10:47 PM >> To: John Cowan >> Cc: xml-dev@l...; public-xml-binary@w... >> Subject: Re: licensing ... [Re: binary XML API and scientific use cases >> [Re: [ANN] nux-1.0beta2 release >> >> >> >> No, that is not right. Eben, who as I mentioned often represents FSF in >> >> some sense and as a technical law professor should know, didn't draw >> that distinction. I would argue that it is an artificial semantic >> conclusion. >> >> LGPL allows you to use a library in a program (or another library) that >> >> has any license, but not distributing a modified library without >> source code. Using a library means any use, while modifying it means >> actually changing the source code that went into the library. >> >> Subclassing is not different semantically from creating a new class with >> >> an instance of the LGPL'd class, creating a corresponding public >> method for every public method in the original class, and calling, >> with or without additional semantics, the corresponding LGPL'd >> method. Both simply use the LGPL'd class without modifying its >> source code. >> >> The intent of LGPL is to allow use of any kind in any kind of program >> while maintaining the integrity of the LGPL'd library. If you >> include the library and decide to call one of your own methods >> instead of one in >> >> the library, you haven't distributed a modified version of the library. >> >> You could in fact distribute a binary-only commercial library or >> application that uses the unmodified LGPL'd library. >> >> sdw >> >> >> John Cowan wrote: >> >> >> >>> Stephen D. Williams scripsit: >>> >>> >>> >>> >>> >>>> Eben: >>>> >>>> The language or programming paradigm in use doesn't determine the >>>> rules >>>> of compliance, nor does whether the GPL'd code has been modified. >>>> The situation is no different than the one where your code depends on >>>> >>> >> static >> >>>> or dynamic linking of a GPL'd library, say GNU readline. Your code, in >>>> >>> >> >> >> >>>> order to operate, must be combined with the GPL'd code, forming a >>>> new combined work, which under GPL section 2(b) must be distributed >>>> under the terms of the GPL and only the GPL. If the author of the >>>> other code >>>> >>> >> >> >> >>>> had chosen to release his JAR under the Lesser GPL, your contribution >>>> >>> >> to >> >>>> the combined work could be released under any license of your >>>> >>> >> choosing, >> >>>> >>>> >>> >>> But that leaves open the question of subclassing. If some >>> application classes are subclasses of classes in the LGPL library, >>> does that make the total application a "work based on the library"? >>> The FSF seems to think so (as does the Apache Software Foundation), >>> because a Java program is essentially one big library. >>> >>> >>> >>> >> >> >> >> >> > > -- The best way to predict the future is to invent it - Alan Kay 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
