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 <btc@openinworld.com>:
On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan@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 <hilaire@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.