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
<mailto:b...@openinworld.com>>:
On Sun, Sep 17, 2017 at 7:00 PM, stephan <step...@stack.nl
<mailto: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
<mailto: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
<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.
