Nothing to add to the particular question, but I'm writing to express how much I disagree when you use adjectives such as "viral" or nouns such as "infection" to describe GPL.
I'm a FSF supporter for a long time, and while I'm used to people choosing not to use free software licenses for the sake of reaching as many business opportunities as possible, I care about the ethics behind the free software movement. I respect people not caring about that fundamental part of the Free Software movement, but I cannot remain silent when everybody seems to share the same unfortunate interpretation of what the GPL is about. 2017-09-17 18:59 GMT+02:00 Ben Coman <b...@openinworld.com>: > On Sun, Sep 17, 2017 at 7:00 PM, stephan <step...@stack.nl> wrote: > > > > On 17-09-17 06:59, Jimmie Houchin wrote: > >> > >> And the GPL not be viral in my app provided I only use the GPL library > and am not modifying it in my app. > >> > >> Do I understand this wrong? > > > > > > Yes. With GPL everything is now GPL. With LGPL, as long as you only link > to it, > > the viral aspect is limited to the library. In Pharo, that means you can > use UFFI > > to connect to LGPL libraries, and you can probably create plugins. > Loading > > smalltalk libraries that are LGPL is not exactly the same as linking, > there is > > no clear boundary between compile-time and run-time, as everything is in > the image. > > That makes the LGPL difficult to interpret in the smalltalk case, and > potentially viral. > > +1. > > > On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hila...@drgeo.eu> wrote: > > Regarding porting GPL software, I guess you mean rewriting with > Smalltalk, > > you should be free to license it as you want, for example as MIT. > > AFAIK there is no evil restriction as "seen the code" under the GPL. > > It is not as clean as that. Many consider "seen the code" to > implicate "derived code". Whether a court of law agrees with this or > not is not what you should consider. The best advice I received from > a lawyer is that winning in court (sometimes after years of effort) is > still a loss, so you should position yourself so that no one even > thinks they can take you court. > > > > For library, alternative is LGPL and I read this interesting note: > > One should note that subclassing a Java (or other OO) class licensed > under the LGPL is regarded as a use of an interface of a library comparable > to a function call of a library. It is not regarded as a modification of > the original class. Therefore the subclass does not fall under the > requirements of the LGPL. > > The definitive reference of Java + LGPL is > https://www.gnu.org/licenses/lgpl-java.en.html > which says: "The typical arrangement for Java is that each library an > application uses is distributed as a separate JAR (Java Archive) file. > Applications use Java's “import” functionality to access classes from > these libraries ... The LGPL permits this distribution ... > Applications need only follow the requirements in section 6 of the > LGPL" > > but a Smalltalk Image runs foul of section 6 requiring... "A suitable > [shared library] mechanism ... 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" where an Image is > considered to be the "executable". > > So incorporating LGPL Smalltalk code into an Image causes all code in > the Image to be infected with the LGPL. > > > > So using a LGPL library, even extending it, does not force the user to > be in the GPL family license. > > Using LGPL C libraries is fine and doesn't infect your Smalltalk code. > Using LGPL Smalltalk libraries does infect all Smalltalk code in your > Image. The concern is contributing a bug fixed in Pharo code from an > infected image technically infects the whole of Pharo - although you > are free to update a clean image with the same bug fix and contribute > from there - but thats an awkward process. > > > > The only restriction is the receiver should be capable to update > > the LGPL package independently of the application using the package. > > Anyway, I don't think you should worried about porting GPL/LGPL > libraries as long > > as your are rewriting it. You can license it under MIT. Then LGPL is > also possible. > > The term "port" clearly implies "derived" so you cannot arbitrarily > re-license just by changing implementation languages. Otherwise for > example a GPL library could be relicensed by one team porting from C > to Python, then a second independent team ports from Python back to C > subverting the original copyright. > > > =============== > Hmmm... actually refreshing myself with the newer license texts just now > I notice GPL 3 has added some interesting definitions the GPL 2 lacks... > > > The “Corresponding Source” for a work ... does not include the work's > System Libraries > > > > The “System Libraries” of an executable work include anything, other > than the work as a whole, that > > (a) is included in the normal form of packaging a Major Component, > > but which is not part of that Major Component, and > > (b) serves only to enable use of the work with that Major Component, or > to implement a > > Standard Interface for which an implementation is available to the > public in source code form. > > > > A “Major Component”, in this context, means a major essential component > > (kernel, window system, and so on) of the specific operating system > (if any) > > on which the executable work runs, or a compiler used to produce the > work, > > or an object code interpreter used to run it. > > > > A “Standard Interface” means an interface that > > ... is widely used among developers working in that language. > > which seems to open the door to a strong argument** that Pharo is such > a Major Component protected from even a full GPL3 coded application > being loaded and run - i.e. you could fix and contribute Pharo code > directly from such an Image - but other non-GPL Smalltalk libraries > you mix in may not be similarly protected. But it still seems a grey > area with compliance easier to manage using nonCopyLeft licenses. > > cheers -ben > > ** You'd probably want the FSF to directly issue a statement on this. > >
