Pharo 7 license question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Pharo 7 license question

Jimmie Houchin-5
Hello,

Pharo 7 to my understanding fundamentally changes Pharo. It is my
understanding that Pharo 7 starts with a core Pharo kernel and like many
languages out there, imports or adds code from a variety of external
sources to the image being built.

With that understanding, I am curious if that would allow for inclusion
of a specific library/module to be licensed as GPL? And it not affect
the other code in the composed image?

I am a big believer in the MIT/BSD license and not a big fan of the GPL.
However, there is software out there that I have avoided looking at the
source code or attempting to port it to Pharo because it is GPL. I would
sincerely love if I could now port such a library and license it under
the GPL as required, and it not affect any other code outside of that
specific library.

I am not a lawyer. Nor do I know any lawyers. Is is possible for someone
to get a reasonably definitive answer on this question?

I am sure I am not the only one who has had this desire. I am also sure
that I am not the only one who will have this question in the future. So
it would be nice to have a proper legal response that could possibly be
explicitly stated somewhere on the website or on an FAQ or something.

Regardless of the answer, yes or no. It does need to be a settled issue
for Pharo. That way someone could know if GPL/LGPL or whatever software
could be in the catalog.

Just wanted to put that out there to the community. I look forward to
the answer, should one be or become available.

Thanks.


Jimmie



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Stephane Ducasse-3
I do not think that the bootstrap changed anything. :)
We will stay away from GPL.
May be you can talk to the people of the libraries you want to use and
see if they are interested in a dual license.

Stef

On Fri, Sep 15, 2017 at 10:49 PM, Jimmie Houchin <[hidden email]> wrote:

> Hello,
>
> Pharo 7 to my understanding fundamentally changes Pharo. It is my
> understanding that Pharo 7 starts with a core Pharo kernel and like many
> languages out there, imports or adds code from a variety of external sources
> to the image being built.
>
> With that understanding, I am curious if that would allow for inclusion of a
> specific library/module to be licensed as GPL? And it not affect the other
> code in the composed image?
>
> I am a big believer in the MIT/BSD license and not a big fan of the GPL.
> However, there is software out there that I have avoided looking at the
> source code or attempting to port it to Pharo because it is GPL. I would
> sincerely love if I could now port such a library and license it under the
> GPL as required, and it not affect any other code outside of that specific
> library.
>
> I am not a lawyer. Nor do I know any lawyers. Is is possible for someone to
> get a reasonably definitive answer on this question?
>
> I am sure I am not the only one who has had this desire. I am also sure that
> I am not the only one who will have this question in the future. So it would
> be nice to have a proper legal response that could possibly be explicitly
> stated somewhere on the website or on an FAQ or something.
>
> Regardless of the answer, yes or no. It does need to be a settled issue for
> Pharo. That way someone could know if GPL/LGPL or whatever software could be
> in the catalog.
>
> Just wanted to put that out there to the community. I look forward to the
> answer, should one be or become available.
>
> Thanks.
>
>
> Jimmie
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Peter Uhnák
someone to get a reasonably definitive answer on this question?

you would get that only from a copyright layer... and definitive answer only from a judge ;)

I don't see how Pharo bootstrap changes anything. If you mean that you can now add library after bootstrap... well you can do that now already with any previous Pharo version.

GPL is viral infection, so if you decide to bundle Pharo with your GPL-ed code, then the whole package will be terminally infected, including all the source code. Pharo or any other loaded libraries in the distro will be considered as GPL. Pharo is under MIT, so you can sublicense it, however if someone decided to contribute some code to your distribution (even if it was to Pharo), the contribution would be considered GPL and only the author would be able to put it to Pharo under the original MIT license.

If you are wondering whether you can distribute Pharo with GPL code linked to it and keep the rest MIT, then the answer is no (and GPL v3 is particularly anal about this, as people are trying to work around it with v2). This is the reason why LGPL exists. LGPL is not contagious.

But again, I don't see how Pharo bootstrap changes any of this.

Peter

On Sat, Sep 16, 2017 at 9:17 AM, Stephane Ducasse <[hidden email]> wrote:
I do not think that the bootstrap changed anything. :)
We will stay away from GPL.
May be you can talk to the people of the libraries you want to use and
see if they are interested in a dual license.

Stef

On Fri, Sep 15, 2017 at 10:49 PM, Jimmie Houchin <[hidden email]> wrote:
> Hello,
>
> Pharo 7 to my understanding fundamentally changes Pharo. It is my
> understanding that Pharo 7 starts with a core Pharo kernel and like many
> languages out there, imports or adds code from a variety of external sources
> to the image being built.
>
> With that understanding, I am curious if that would allow for inclusion of a
> specific library/module to be licensed as GPL? And it not affect the other
> code in the composed image?
>
> I am a big believer in the MIT/BSD license and not a big fan of the GPL.
> However, there is software out there that I have avoided looking at the
> source code or attempting to port it to Pharo because it is GPL. I would
> sincerely love if I could now port such a library and license it under the
> GPL as required, and it not affect any other code outside of that specific
> library.
>
> I am not a lawyer. Nor do I know any lawyers. Is is possible for someone to
> get a reasonably definitive answer on this question?
>
> I am sure I am not the only one who has had this desire. I am also sure that
> I am not the only one who will have this question in the future. So it would
> be nice to have a proper legal response that could possibly be explicitly
> stated somewhere on the website or on an FAQ or something.
>
> Regardless of the answer, yes or no. It does need to be a settled issue for
> Pharo. That way someone could know if GPL/LGPL or whatever software could be
> in the catalog.
>
> Just wanted to put that out there to the community. I look forward to the
> answer, should one be or become available.
>
> Thanks.
>
>
> Jimmie
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Stephan Eggermont-3
On 16-09-17 18:51, Peter Uhnák wrote:
>   This is the reason why LGPL exists. LGPL is not contagious.

It is not clear that that would be the case with smalltalk.
We tend to reuse by subclassing, and linking is not so
well-defined. There is no license that has the same effect as
LGPL has for c programs for smalltalk.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Jimmie Houchin-5
In reply to this post by Stephane Ducasse-3
I understand that Pharo people will in general want to stay away from
the GPL. I just didn't know if it would potentially be more equivalent
to how other languages work.

In Python to my understanding I could do something like

#into my MIT licensed app
import GPL_library
import MIT_library

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?

I haven't yet investigated Pharo 7 yet, so I do not know what would be
similar to the above.

MyMITClass #initialize
     "Install configurationOfGPL package"
     self useGPLPackage

Yes it is contrived. But I am trying to see why Pharo would be different?

Both are loading GPL code and running it in a mixed system.

Regarding dual-licensing. I don't think that is likely. Most of these
people prefer the GPL and use it because they want its viral nature and
dislike the permissiveness of MIT software. They want to constrain they
software.

Thanks to all who replied. I just thought I would ask.

Jimmie



On 09/16/2017 02:17 AM, Stephane Ducasse wrote:

> I do not think that the bootstrap changed anything. :)
> We will stay away from GPL.
> May be you can talk to the people of the libraries you want to use and
> see if they are interested in a dual license.
>
> Stef
>
> On Fri, Sep 15, 2017 at 10:49 PM, Jimmie Houchin <[hidden email]> wrote:
>> Hello,
>>
>> Pharo 7 to my understanding fundamentally changes Pharo. It is my
>> understanding that Pharo 7 starts with a core Pharo kernel and like many
>> languages out there, imports or adds code from a variety of external sources
>> to the image being built.
>>
>> With that understanding, I am curious if that would allow for inclusion of a
>> specific library/module to be licensed as GPL? And it not affect the other
>> code in the composed image?
>>
>> I am a big believer in the MIT/BSD license and not a big fan of the GPL.
>> However, there is software out there that I have avoided looking at the
>> source code or attempting to port it to Pharo because it is GPL. I would
>> sincerely love if I could now port such a library and license it under the
>> GPL as required, and it not affect any other code outside of that specific
>> library.
>>
>> I am not a lawyer. Nor do I know any lawyers. Is is possible for someone to
>> get a reasonably definitive answer on this question?
>>
>> I am sure I am not the only one who has had this desire. I am also sure that
>> I am not the only one who will have this question in the future. So it would
>> be nice to have a proper legal response that could possibly be explicitly
>> stated somewhere on the website or on an FAQ or something.
>>
>> Regardless of the answer, yes or no. It does need to be a settled issue for
>> Pharo. That way someone could know if GPL/LGPL or whatever software could be
>> in the catalog.
>>
>> Just wanted to put that out there to the community. I look forward to the
>> answer, should one be or become available.
>>
>> Thanks.
>>
>>
>> Jimmie
>>
>>
>>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

HilaireFernandes
In reply to this post by Jimmie Houchin-5

Hi Jimmie,

Dr. Geo is distributed under the GPL and shipped with Pharo.

As Pharo is MIT, you can redistribute your whole software under the license you want, proprietary or free software ones as GPL.

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.

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.

So using a LGPL library, even extending it, does not force the user to be in the GPL family license.

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.


-- 
Dr. Geo
http://drgeo.eu
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Pierce Ng-3
In reply to this post by Stephan Eggermont-3
On Sun, Sep 17, 2017 at 02:47:16AM +0200, stephan wrote:
> On 16-09-17 18:51, Peter Uhnák wrote:
> >  This is the reason why LGPL exists. LGPL is not contagious.
>
> It is not clear that that would be the case with smalltalk.
> We tend to reuse by subclassing, and linking is not so
> well-defined. There is no license that has the same effect as
> LGPL has for c programs for smalltalk.

The Common Lisp people have LLGPL:

  http://www.cliki.net/LLGPL
  http://opensource.franz.com/preamble.html

Pierce


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Stephan Eggermont-3
In reply to this post by HilaireFernandes
On 17-09-17 12:09, Hilaire wrote:

> 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.
>
> So using a LGPL library, even extending it, does not force the user to
> be in the GPL family license.

Loading an LGPL library in a smalltalk image is not linking, in the
strict interpretation. So no. FSF is aware of this problem

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Stephan Eggermont-3
In reply to this post by Jimmie Houchin-5
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.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

kilon.alios
In reply to this post by Jimmie Houchin-5
Mr lawyer here
I will give you general direction because in the end it depends in the national law of the country of the person being sued. 

The general idea is that GPL is a license to be avoided if you want real freedom for your users. That means their ability to open or close code. 

A license is in essense a contract that you accept when you click a button, a link or other means that show clear consent. If the license is not accepted through the means provided by law then it cannot apply. Also a license is bound by law and national laws have special legislation of what contracts can have as terms. Anything that may cause bodily harm for example or negate the liability for such action are terms in the a contract that are immediately become invalid and hence they dont apply without necessarily make the whole contract invalid. Basically means that a license by itself is powerless and can function only under the permissions of law. 

A GPL license is thus a contract, but a GPL license as we all know it, generally is used as a template. None forces anyone from making a GPL license that allows the the user to close the code. FSF could sue for the use of the name on the ground of misleading the user, but the license would be still valid. 

Matter complicate also on the matter of GPL "infection". One licences his code under MIT but uses GPL licensed libraries, keeping his code open does not violate GPL but if another user take the code and add his own code to it and close it , including the GPL license he does violate the GPL license but does he violate the law ? 

My legal opinion on this is that he does not unless there was clear consent by him on the matter of GPL license, which would require for him to know that those libraries are used by the MIT code he is using and those libraries are GPL. Taking into account how messy code bases can  be, good luck with that. 

Again this depends on case and national law , hence why we say always , go speak with a lawyer of your juridiction , preferably someone who specialises in contract law. NOT Copyright law. A license has little to do with ownership , which is what copyright is, its merely a contract trying to bind you to use the code only in specific ways. Violation of a license is not a violation of copyright. Again under the exclusion of national laws, national laws have each their own weirdnesses.  

Also another advice, it does not matter if the license is called MIT, GPL, BSD , BOOGIE , or BIGPINKELEPHANT , the bottom line is that licenses are contracts and as such as soon as you accept them they are biding to the extend the law allows them to be binding , as I mentioned earlier

Thus....

When we venture into the commercial world and profit is involved, people who will want a piece of that profit may emerge and use the license against you. Thus do not accept any license even if it is certified MIT before giving the text to a lawyer to read it and find any traps , hidden doors or anything that can put you in a compromising position. 

There are even cases when both parties have good intentions yet they entangle in a legal battle because the license is too vague, confusing or it does not specify a special case that may apply. 

Contracts can be extremely complex entities, even though I am not a copyright lawyer , I do general practice and martitime law, that Greek Law and European Law by the way, I know how hairy things can get , especially with big contracts. I also have a single experience with Copyright of the code , between an individual and the company and it was very very messy for both parties. Unfortunately judges still do not understand computers and I can tell you that also apples to other European countries and the USA because I have a master degreen on commercial and e-commerce from a UK uinversity with a disertation "Legal protections against malicious software". I examined UK, Eurpean and International law for this dissertation and what I have seen has severely disappointed me how law professionals, not just judges are so clueless when it comes to technology and yet are expected to provide fair protection and judgements. 

Summary : If you plan to make profit, go talk with your lawyer. If you intend to make a company a lawyer and an accountant is a MUST HAVE and wil save you tons of money than they will cost you. Also never wait for the last second to seek legal advise , in law everything is under a time limit, you dont want to be late. Trust me ;) 


On Sun, Sep 17, 2017 at 8:01 AM Jimmie Houchin <[hidden email]> wrote:
I understand that Pharo people will in general want to stay away from
the GPL. I just didn't know if it would potentially be more equivalent
to how other languages work.

In Python to my understanding I could do something like

#into my MIT licensed app
import GPL_library
import MIT_library

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?

I haven't yet investigated Pharo 7 yet, so I do not know what would be
similar to the above.

MyMITClass #initialize
     "Install configurationOfGPL package"
     self useGPLPackage

Yes it is contrived. But I am trying to see why Pharo would be different?

Both are loading GPL code and running it in a mixed system.

Regarding dual-licensing. I don't think that is likely. Most of these
people prefer the GPL and use it because they want its viral nature and
dislike the permissiveness of MIT software. They want to constrain they
software.

Thanks to all who replied. I just thought I would ask.

Jimmie



On 09/16/2017 02:17 AM, Stephane Ducasse wrote:
> I do not think that the bootstrap changed anything. :)
> We will stay away from GPL.
> May be you can talk to the people of the libraries you want to use and
> see if they are interested in a dual license.
>
> Stef
>
> On Fri, Sep 15, 2017 at 10:49 PM, Jimmie Houchin <[hidden email]> wrote:
>> Hello,
>>
>> Pharo 7 to my understanding fundamentally changes Pharo. It is my
>> understanding that Pharo 7 starts with a core Pharo kernel and like many
>> languages out there, imports or adds code from a variety of external sources
>> to the image being built.
>>
>> With that understanding, I am curious if that would allow for inclusion of a
>> specific library/module to be licensed as GPL? And it not affect the other
>> code in the composed image?
>>
>> I am a big believer in the MIT/BSD license and not a big fan of the GPL.
>> However, there is software out there that I have avoided looking at the
>> source code or attempting to port it to Pharo because it is GPL. I would
>> sincerely love if I could now port such a library and license it under the
>> GPL as required, and it not affect any other code outside of that specific
>> library.
>>
>> I am not a lawyer. Nor do I know any lawyers. Is is possible for someone to
>> get a reasonably definitive answer on this question?
>>
>> I am sure I am not the only one who has had this desire. I am also sure that
>> I am not the only one who will have this question in the future. So it would
>> be nice to have a proper legal response that could possibly be explicitly
>> stated somewhere on the website or on an FAQ or something.
>>
>> Regardless of the answer, yes or no. It does need to be a settled issue for
>> Pharo. That way someone could know if GPL/LGPL or whatever software could be
>> in the catalog.
>>
>> Just wanted to put that out there to the community. I look forward to the
>> answer, should one be or become available.
>>
>> Thanks.
>>
>>
>> Jimmie
>>
>>
>>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Ben Coman
In reply to this post by Stephan Eggermont-3
On Sun, Sep 17, 2017 at 7:00 PM, stephan <[hidden email]> 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Jose San Leandro
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 <[hidden email]>:
On Sun, Sep 17, 2017 at 7:00 PM, stephan <[hidden email]> 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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Jimmie Houchin-5

Hello,

As the person who initially used the word viral in this thread, let me ask you a question.

Personally I greatly dislike the GPL and variants. I and many believe viral is what describes that nature of the GPL. However, I recognize that there are reasonable people who like the GPL and greatly like that aspect of its license. It is viral and does infect. It is seen by many people something to avoid, just as one would avoid a virus or infection. Yes these are negative terms.

You protest our use of these terms but do not offer alternatives that you prefer. In the absence of acceptable alternatives that GPL proponents prefer, then we left to terms that we naturally gravitate toward using. So let me suggest that when you make your opinion heard, please include what you would prefer. Otherwise it doesn't really help you with your expressed desires of us not using said terminology.

So my question to you. What words would you use instead of viral and infection that equally describe that characteristic of the GPL and variants?

Thanks.

Jimmie


On 09/20/2017 02:10 PM, Jose San Leandro wrote:
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 <[hidden email]>:
On Sun, Sep 17, 2017 at 7:00 PM, stephan <[hidden email]> 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 <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Sven Van Caekenberghe-2
In reply to this post by Jose San Leandro

> On 20 Sep 2017, at 21:10, Jose San Leandro <[hidden email]> wrote:
>
> 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.

I agree, well said.

On ethical grounds I would certainly choose a modern GPL (like AGPLv3). I want my work to benefit the public and remain like that. The fact that someone can take it and sell it goes against the idea of open source.

But for a Smalltalk system aiming to commercial use, MIT is the only way forward.

> 2017-09-17 18:59 GMT+02:00 Ben Coman <[hidden email]>:
> On Sun, Sep 17, 2017 at 7:00 PM, stephan <[hidden email]> 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 <[hidden email]> 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.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Jose San Leandro
In reply to this post by Jimmie Houchin-5
Hi,

I was afraid this would hijack the thread, and didn't want to.

I don't like these metaphors, and my attempt to answer your question may be better, or less obvious, but I think "viral" and "infection" only describe the GPL when your mindset does not care about the freedoms the GPL tries to preserve.
I'd say "effective against people trying to restrict the rights the GPL defends" instead of "viral".
The "infection" interpretation comes from the idea that the GPL restricts freedom, which is a trap. We may be used not to care about certain rights, or think they are secondary or even worthless. Then, when the GPL forces us not to restrict those rights, and we still don't care about what the GPL is trying to protect, we can conclude the GPL is a dangerous infection that restricts our freedom of choice.
GPL is a mechanism to defend users. Software vendors used to limit users' rights obviously get their "rights" limited. The GPL does not respect the right to restrict others' rights.

Anyway, I'm not here to judge. MIT may be the most convenient license for Pharo nowadays. I'm not discussing that. I just couldn't remain silent thinking there's an obvious consensus that GPL is "viral" or an "infection" and that should be avoided at all costs.

2017-09-20 21:30 GMT+02:00 Jimmie Houchin <[hidden email]>:

Hello,

As the person who initially used the word viral in this thread, let me ask you a question.

Personally I greatly dislike the GPL and variants. I and many believe viral is what describes that nature of the GPL. However, I recognize that there are reasonable people who like the GPL and greatly like that aspect of its license. It is viral and does infect. It is seen by many people something to avoid, just as one would avoid a virus or infection. Yes these are negative terms.

You protest our use of these terms but do not offer alternatives that you prefer. In the absence of acceptable alternatives that GPL proponents prefer, then we left to terms that we naturally gravitate toward using. So let me suggest that when you make your opinion heard, please include what you would prefer. Otherwise it doesn't really help you with your expressed desires of us not using said terminology.

So my question to you. What words would you use instead of viral and infection that equally describe that characteristic of the GPL and variants?

Thanks.

Jimmie


On 09/20/2017 02:10 PM, Jose San Leandro wrote:
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 <[hidden email]>:
On Sun, Sep 17, 2017 at 7:00 PM, stephan <[hidden email]> 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 <[hidden email]> 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.




Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Jimmie Houchin-5

Please, feel free to participate. You are not hijacking anything, you are voicing your opinion and participating in the community. This is good. We don't all have to have the same opinion or values. People expressing their opinion is a valuable part of any community. We may agree or disagree, but it helps in understanding each other.

Here is how I view this.

GPL restricts my rights as a "user" to preserve the rights of the author. I (author) do not want you (user) to use my software in any way that I (author) do not approve of.

GPL is viral. It is not viral because of what it wants to preserve. It is viral because in many cases it compels (forces) users to change the license of the software in their system to the GPL. This is why Pharo can not use GPL. Because it would force all of Pharo to become GPL. This is expressly what the authors of the GPL wanted. It is expressly what the authors of Pharo do not want.

It is viral because of what it does, how it behaves, what it forces. Not because of what it preserves. The viral nature isn't preserving the original GPL software, but rather infecting somebody else's software. Which is why I asked my question. If I ported GPL software would that license affect anything more than what I wrote. The most common answer was YES. It would affect everything or infect everything.

I don't care about a small piece being GPL. I care about how it impacts the bigger piece.

You say it defends rights. It just removed my right to license my software how I wish. The only way to preserve that option is to not use GPL software.

Now, should I choose to not use GPL software. How has that benefited anybody in the GPL ecosystem? Not at all.

We like to talk about the bad big corporation stealing our hard work and our software and making millions of dollars. Yes big corp. prefers MIT/BSD. They also prefer to release their own hard work and dollars as MIT/BSD licensed software. It isn't as if it is all take on big corporation's side. They prefer the permissive license both as author and user.

MIT/BSD simply says you the user may do anything you want. Just don't blame me (author) for anything. And give author(s) credit for what they have created.

I would rather have people, businesses believe in open source software and use and release open source software because they are believers and not because some license forced them to do so. That is how MIT/BSD software is. And in reality it is how all authors of open source software are regardless of license. They do it because the believe in it. It is wrong to think that MIT authors don't believe in the freedoms of open source software. We do. We want the user to reciprocate because they believe, not because we forced them. You can't force anybody. They always have the choice of choosing something different, or writing it themselves.

Enough rambling. Even though we very much disagree. Do not be silent. Participate. We all learn.

Jimmie



On 09/20/2017 02:57 PM, Jose San Leandro wrote:
Hi,

I was afraid this would hijack the thread, and didn't want to.

I don't like these metaphors, and my attempt to answer your question may be better, or less obvious, but I think "viral" and "infection" only describe the GPL when your mindset does not care about the freedoms the GPL tries to preserve.
I'd say "effective against people trying to restrict the rights the GPL defends" instead of "viral".
The "infection" interpretation comes from the idea that the GPL restricts freedom, which is a trap. We may be used not to care about certain rights, or think they are secondary or even worthless. Then, when the GPL forces us not to restrict those rights, and we still don't care about what the GPL is trying to protect, we can conclude the GPL is a dangerous infection that restricts our freedom of choice.
GPL is a mechanism to defend users. Software vendors used to limit users' rights obviously get their "rights" limited. The GPL does not respect the right to restrict others' rights.

Anyway, I'm not here to judge. MIT may be the most convenient license for Pharo nowadays. I'm not discussing that. I just couldn't remain silent thinking there's an obvious consensus that GPL is "viral" or an "infection" and that should be avoided at all costs.

2017-09-20 21:30 GMT+02:00 Jimmie Houchin <[hidden email]>:

Hello,

As the person who initially used the word viral in this thread, let me ask you a question.

Personally I greatly dislike the GPL and variants. I and many believe viral is what describes that nature of the GPL. However, I recognize that there are reasonable people who like the GPL and greatly like that aspect of its license. It is viral and does infect. It is seen by many people something to avoid, just as one would avoid a virus or infection. Yes these are negative terms.

You protest our use of these terms but do not offer alternatives that you prefer. In the absence of acceptable alternatives that GPL proponents prefer, then we left to terms that we naturally gravitate toward using. So let me suggest that when you make your opinion heard, please include what you would prefer. Otherwise it doesn't really help you with your expressed desires of us not using said terminology.

So my question to you. What words would you use instead of viral and infection that equally describe that characteristic of the GPL and variants?

Thanks.

Jimmie


On 09/20/2017 02:10 PM, Jose San Leandro wrote:
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 <[hidden email]>:
On Sun, Sep 17, 2017 at 7:00 PM, stephan <[hidden email]> 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 <[hidden email]> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Ben Coman
In reply to this post by Jose San Leandro

On Thu, Sep 21, 2017 at 3:57 AM, Jose San Leandro <[hidden email]> wrote:
Hi,

I was afraid this would hijack the thread, and didn't want to.

No worries. Its pertinent to the topic. Licensing is a bit arcane and various viewpoints are useful.

I support FSF ideals (I have a hardcopy of Stallman's book [http://a.co/aso0v7W])
and believe the GPL is appropriate for a lot of software - particularly off-the-shelf / end-user oriented software, but less appropriate for bespoke software written under contract for a specific company, (e.g. their business web site) which is the market Pharo is hoping its user-developers succeed. 
[http://ballardchalmers.com/2016/03/27/bespoke-software-outgunning-off-the-shelf-software/]

I don't like these metaphors, and my attempt to answer your question may be better, or less obvious, but I think "viral" and "infection" only describe the GPL when your mindset does not care about the freedoms the GPL tries to preserve.

The essential MIT/GPL license differences is how they treat free-riders and downstream user rights. You seem concerned with the latter, which is why the GPL is suited for end-user / packaged / off-the-shelf software.  But Pharo's user-developers don't control the views of the companies they contract to, and forcing the GPL as the only licensing option may have a chilling effect on the ability gain engagements.  So the Pharo mindset is to preserve the freedom of its user-developer's to negotiate the terms of their contracts with their clients.  

From that position, what makes the GPL viral is the clause "You may convey a work based on the Program ... provided that you ... license the entire work, as a whole."  

So I have the freedom to distribute an application combining three libraries with separate MIT, BSD and Apache licenses while maintaining those original licenses. But add a GPL library, and now my application must distribute the other three libraries also under the GPL. Thats viral.
 
I'd say "effective against people trying to restrict the rights the GPL defends" instead of "viral".

Sorry to be glib, but viral is a lot simpler (for those of a certain mindset). 
 
The "infection" interpretation comes from the idea that the GPL restricts freedom, which is a trap. We may be used not to care about certain rights, or think they are secondary or even worthless. Then, when the GPL forces us not to restrict those rights, and we still don't care about what the GPL is trying to protect, we can conclude the GPL is a dangerous infection that restricts our freedom of choice.

GPL is a mechanism to defend users. Software vendors used to limit users' rights obviously get their "rights" limited. The GPL does not respect the right to restrict others' rights.

Its horses for courses.  No one viewpoint fits all circumstances. Another way to look at it is that permissive licenses give a developer more freedom to combine libraries with different licenses.  

I do like this radical simplification I bumped into... 
"Another way of looking at it is that you’re picking a license based on what you are afraid of. 
* The MIT license is if you’re afraid no one will use your code; you’re making the licensing as short and non-intimidating as possible. 
* The Apache License you are somewhat afraid of no one using your code, but you are also afraid of legal ambiguity and patent trolls. 
* With the GPL licenses, you are afraid of someone else profiting from your work [or profiting off end-users] (and ambiguity, and patent trolls)." [https://exygy.com/which-license-should-i-use-mit-vs-apache-vs-gpl]

...which aligns squarely with Pharo - our greater fear is people not using it.
 

Anyway, I'm not here to judge. MIT may be the most convenient license for Pharo nowadays. I'm not discussing that. I just couldn't remain silent thinking there's an obvious consensus that GPL is "viral" or an "infection" and that should be avoided at all costs.

cool.  
cheers -ben
 

2017-09-20 21:30 GMT+02:00 Jimmie Houchin <[hidden email]>:

Hello,

As the person who initially used the word viral in this thread, let me ask you a question.

Personally I greatly dislike the GPL and variants. I and many believe viral is what describes that nature of the GPL. However, I recognize that there are reasonable people who like the GPL and greatly like that aspect of its license. It is viral and does infect. It is seen by many people something to avoid, just as one would avoid a virus or infection. Yes these are negative terms.

You protest our use of these terms but do not offer alternatives that you prefer. In the absence of acceptable alternatives that GPL proponents prefer, then we left to terms that we naturally gravitate toward using. So let me suggest that when you make your opinion heard, please include what you would prefer. Otherwise it doesn't really help you with your expressed desires of us not using said terminology.

So my question to you. What words would you use instead of viral and infection that equally describe that characteristic of the GPL and variants?

Thanks.

Jimmie


On 09/20/2017 02:10 PM, Jose San Leandro wrote:
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 <[hidden email]>:
On Sun, Sep 17, 2017 at 7:00 PM, stephan <[hidden email]> 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 <[hidden email]> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Jimmie Houchin-5
On 09/21/2017 09:47 AM, Ben Coman wrote:
[SNIP]
Its horses for courses.  No one viewpoint fits all circumstances. Another way to look at it is that permissive licenses give a developer more freedom to combine libraries with different licenses.  

I do like this radical simplification I bumped into... 
"Another way of looking at it is that you’re picking a license based on what you are afraid of. 
* The MIT license is if you’re afraid no one will use your code; you’re making the licensing as short and non-intimidating as possible. 
* The Apache License you are somewhat afraid of no one using your code, but you are also afraid of legal ambiguity and patent trolls. 
* With the GPL licenses, you are afraid of someone else profiting from your work [or profiting off end-users] (and ambiguity, and patent trolls)." [https://exygy.com/which-license-should-i-use-mit-vs-apache-vs-gpl]

...which aligns squarely with Pharo - our greater fear is people not using it.

I think the GPL one looks right. Fear, anger, offense if someone has the possibility of using their software and not contributing back. To me I think it doesn't work as much as they think. It doesn't take into account the free will of people to walk away and completely not use their software. I personally don't even look at GPL licensed sources unless there are none other available which is very rare. I don't want the knowledge or understanding of that code tainting other code I write.

MIT often means, we don't care, do what you want, just don't blame us.
We don't care if you take it and use it in closed source proprietary money making big corp software.
We don't care if you take it and use it and keep it to yourself.
We don't care ... Just don't blame us for any problems.

However, we would love your buy in on open source philosophy and contribute back where you are able. We understand you have software which is business critical, proprietary and can not be open sourced. We also know that you probably have software which has no business specific (your business) code which is releasable. And we see many, many, big and small businesses doing so today. Close off what you must, open what you can.

I don't think most of us are afraid of no one using our code. PostgreSQL has no such fear. SQLite which is public domain has no such fear. And we could go on and on. Python, etc...

I personally am very much in the camp of I want people to contribute because they want to contribute. Not because I have a stick called the GPL. But rather because I have the carrot of all of the benefits derived from open source software. I am carrot oriented, not stick oriented.

Jimmie


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Herby Vojčík
In reply to this post by Jimmie Houchin-5
Jimmie Houchin wrote:

> You say it defends rights. It just removed my right to license my
> software how I wish. The only way to preserve that option is to not use
> GPL software.
>
> Now, should I choose to not use GPL software. How has that benefited
> anybody in the GPL ecosystem? Not at all.
>
> We like to talk about the bad big corporation stealing our hard work and
> our software and making millions of dollars. Yes big corp. prefers
> MIT/BSD. They also prefer to release their own hard work and dollars as
> MIT/BSD licensed software. It isn't as if it is all take on big
> corporation's side. They prefer the permissive license both as author
> and user.
>
> MIT/BSD simply says you the user may do anything you want. Just don't
> blame me (author) for anything. And give author(s) credit for what they
> have created.
>
> I would rather have people, businesses believe in open source software
> and use and release open source software because they are believers and
> not because some license forced them to do so. That is how MIT/BSD
> software is. And in reality it is how all authors of open source
> software are regardless of license. They do it because the believe in
> it. It is wrong to think that MIT authors don't believe in the freedoms
> of open source software. We do. We want the user to reciprocate because
> they believe, not because we forced them. You can't force anybody. They
> always have the choice of choosing something different, or writing it
> themselves.

+1

> Jimmie

Herby

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 7 license question

Jose San Leandro
In reply to this post by Jimmie Houchin-5
I personally don't care about the interests of big corporations cheating with end-users' rights. If they were my potential customers, or any intermediary which is afraid of not being able to do business with them due to their obsession with restricting end-users' rights, then I'd probably have a conflict of interest. In that case, I could think of sacrificing ethics for food temporarily. But I'm not in that business, and I don't want to.

I won't blame the GPL instead of the "old culture" of doing business by forcing customers to do only what you want them to do, and make them pay for any upgrade some of them could do themselves otherwise.

Distributing works with GPL restricts the options to other developers using your product or library. No doubt about that. But ethically, that "freedom" only helps the old model of doing software. All software should be GPLd in the first place.

There's a book that indirectly illustrates my point, and one I enthusiastically recommend: Badass users [1].

Anyway, we could go on and on. It's a matter of pragmatism vs ethics of software.

Usually, people sharing your "classic" point of view of the business of software don't understand why people write free software and give it for free.
Is that your case?


2017-09-21 17:16 GMT+02:00 Jimmie Houchin <[hidden email]>:
On 09/21/2017 09:47 AM, Ben Coman wrote:
[SNIP]
Its horses for courses.  No one viewpoint fits all circumstances. Another way to look at it is that permissive licenses give a developer more freedom to combine libraries with different licenses.  

I do like this radical simplification I bumped into... 
"Another way of looking at it is that you’re picking a license based on what you are afraid of. 
* The MIT license is if you’re afraid no one will use your code; you’re making the licensing as short and non-intimidating as possible. 
* The Apache License you are somewhat afraid of no one using your code, but you are also afraid of legal ambiguity and patent trolls. 
* With the GPL licenses, you are afraid of someone else profiting from your work [or profiting off end-users] (and ambiguity, and patent trolls)." [https://exygy.com/which-license-should-i-use-mit-vs-apache-vs-gpl]

...which aligns squarely with Pharo - our greater fear is people not using it.

I think the GPL one looks right. Fear, anger, offense if someone has the possibility of using their software and not contributing back. To me I think it doesn't work as much as they think. It doesn't take into account the free will of people to walk away and completely not use their software. I personally don't even look at GPL licensed sources unless there are none other available which is very rare. I don't want the knowledge or understanding of that code tainting other code I write.

MIT often means, we don't care, do what you want, just don't blame us.
We don't care if you take it and use it in closed source proprietary money making big corp software.
We don't care if you take it and use it and keep it to yourself.
We don't care ... Just don't blame us for any problems.

However, we would love your buy in on open source philosophy and contribute back where you are able. We understand you have software which is business critical, proprietary and can not be open sourced. We also know that you probably have software which has no business specific (your business) code which is releasable. And we see many, many, big and small businesses doing so today. Close off what you must, open what you can.

I don't think most of us are afraid of no one using our code. PostgreSQL has no such fear. SQLite which is public domain has no such fear. And we could go on and on. Python, etc...

I personally am very much in the camp of I want people to contribute because they want to contribute. Not because I have a stick called the GPL. But rather because I have the carrot of all of the benefits derived from open source software. I am carrot oriented, not stick oriented.

Jimmie



123