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

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 <jlhouchin@gmail.com> 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

On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan@stack.nl> wrote:

On 17-09-17 06:59, Jimmie Houchin wrote:

...

And the GPL not be viral in my app provided I only use the GPL library and am not modifying it in my app.

Do I understand this wrong?

Yes. With GPL everything is now GPL. With LGPL, as long as you only link to it, the viral aspect is limited to the library. In Pharo, that means you can use UFFI to connect to LGPL libraries, and you can probably create plugins. Loading smalltalk libraries that are LGPL is not exactly the same as linking, there is no clear boundary between compile-time and run-time, as everything is in the image. That makes the LGPL difficult to interpret in the smalltalk case, and potentially viral.

+1. On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hilaire@drgeo.eu> wrote:

Regarding porting GPL software, I guess you mean rewriting with Smalltalk, you should be free to license it as you want, for example as MIT. AFAIK there is no evil restriction as "seen the code" under the GPL.

It is not as clean as that. Many consider "seen the code" to implicate "derived code". Whether a court of law agrees with this or not is not what you should consider. The best advice I received from a lawyer is that winning in court (sometimes after years of effort) is still a loss, so you should position yourself so that no one even thinks they can take you court.

For library, alternative is LGPL and I read this interesting note: One should note that subclassing a Java (or other OO) class licensed under the LGPL is regarded as a use of an interface of a library comparable to a function call of a library. It is not regarded as a modification of the original class. Therefore the subclass does not fall under the requirements of the LGPL.

The definitive reference of Java + LGPL is https://www.gnu.org/licenses/lgpl-java.en.html which says: "The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries ... The LGPL permits this distribution ... Applications need only follow the requirements in section 6 of the LGPL" but a Smalltalk Image runs foul of section 6 requiring... "A suitable [shared library] mechanism ... that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable" where an Image is considered to be the "executable". So incorporating LGPL Smalltalk code into an Image causes all code in the Image to be infected with the LGPL.

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

Using LGPL C libraries is fine and doesn't infect your Smalltalk code. Using LGPL Smalltalk libraries does infect all Smalltalk code in your Image. The concern is contributing a bug fixed in Pharo code from an infected image technically infects the whole of Pharo - although you are free to update a clean image with the same bug fix and contribute from there - but thats an awkward process.

The only restriction is the receiver should be capable to update the LGPL package independently of the application using the package. Anyway, I don't think you should worried about porting GPL/LGPL libraries as long as your are rewriting it. You can license it under MIT. Then LGPL is also possible.

The term "port" clearly implies "derived" so you cannot arbitrarily re-license just by changing implementation languages. Otherwise for example a GPL library could be relicensed by one team porting from C to Python, then a second independent team ports from Python back to C subverting the original copyright. =============== Hmmm... actually refreshing myself with the newer license texts just now I notice GPL 3 has added some interesting definitions the GPL 2 lacks...

The “Corresponding Source” for a work ... does not include the work's System Libraries

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form.

A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

A “Standard Interface” means an interface that ... is widely used among developers working in that language.

which seems to open the door to a strong argument** that Pharo is such a Major Component protected from even a full GPL3 coded application being loaded and run - i.e. you could fix and contribute Pharo code directly from such an Image - but other non-GPL Smalltalk libraries you mix in may not be similarly protected. But it still seems a grey area with compliance easier to manage using nonCopyLeft licenses. cheers -ben ** You'd probably want the FSF to directly issue a statement on this.

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 <btc@openinworld.com <mailto:btc@openinworld.com>>:

On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan@stack.nl <mailto:stephan@stack.nl>> wrote: > > On 17-09-17 06:59, Jimmie Houchin wrote: >> >> And the GPL not be viral in my app provided I only use the GPL library and am not modifying it in my app. >> >> Do I understand this wrong? > > > Yes. With GPL everything is now GPL. With LGPL, as long as you only link to it, > the viral aspect is limited to the library. In Pharo, that means you can use UFFI > to connect to LGPL libraries, and you can probably create plugins. Loading > smalltalk libraries that are LGPL is not exactly the same as linking, there is > no clear boundary between compile-time and run-time, as everything is in the image. > That makes the LGPL difficult to interpret in the smalltalk case, and potentially viral.

+1.

On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>> wrote: > Regarding porting GPL software, I guess you mean rewriting with Smalltalk, > you should be free to license it as you want, for example as MIT. > AFAIK there is no evil restriction as "seen the code" under the GPL.

It is not as clean as that.  Many consider "seen the code" to implicate "derived code".  Whether a court of law agrees with this or not is not what you should consider.   The best advice I received from a lawyer is that winning in court (sometimes after years of effort) is still a loss, so you should position yourself so that no one even thinks they can take you court.

> For library, alternative is LGPL and I read this interesting note: > One should note that subclassing a Java (or other OO) class licensed under the LGPL is regarded as a use of an interface of a library comparable to a function call of a library. It is not regarded as a modification of the original class. Therefore the subclass does not fall under the requirements of the LGPL.

The definitive reference of Java + LGPL is https://www.gnu.org/licenses/lgpl-java.en.html <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.

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 <jlhouchin@gmail.com <mailto:jlhouchin@gmail.com>>:

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 <btc@openinworld.com <mailto:btc@openinworld.com>>:

On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan@stack.nl <mailto:stephan@stack.nl>> wrote: > > On 17-09-17 06:59, Jimmie Houchin wrote: >> >> And the GPL not be viral in my app provided I only use the GPL library and am not modifying it in my app. >> >> Do I understand this wrong? > > > Yes. With GPL everything is now GPL. With LGPL, as long as you only link to it, > the viral aspect is limited to the library. In Pharo, that means you can use UFFI > to connect to LGPL libraries, and you can probably create plugins. Loading > smalltalk libraries that are LGPL is not exactly the same as linking, there is > no clear boundary between compile-time and run-time, as everything is in the image. > That makes the LGPL difficult to interpret in the smalltalk case, and potentially viral.

+1.

On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>> wrote: > Regarding porting GPL software, I guess you mean rewriting with Smalltalk, > you should be free to license it as you want, for example as MIT. > AFAIK there is no evil restriction as "seen the code" under the GPL.

It is not as clean as that.  Many consider "seen the code" to implicate "derived code".  Whether a court of law agrees with this or not is not what you should consider.   The best advice I received from a lawyer is that winning in court (sometimes after years of effort) is still a loss, so you should position yourself so that no one even thinks they can take you court.

> For library, alternative is LGPL and I read this interesting note: > One should note that subclassing a Java (or other OO) class licensed under the LGPL is regarded as a use of an interface of a library comparable to a function call of a library. It is not regarded as a modification of the original class. Therefore the subclass does not fall under the requirements of the LGPL.

The definitive reference of Java + LGPL is https://www.gnu.org/licenses/lgpl-java.en.html <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.

On Thu, Sep 21, 2017 at 3:57 AM, Jose San Leandro <jose.sanleandro@osoco.es> 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-sh... ] 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 <jlhouchin@gmail.com>:

...

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 <btc@openinworld.com>:

...

On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan@stack.nl> wrote:

...

On 17-09-17 06:59, Jimmie Houchin wrote:

...

And the GPL not be viral in my app provided I only use the GPL

library and am not modifying it in my app.

...

...

Do I understand this wrong?

Yes. With GPL everything is now GPL. With LGPL, as long as you only link to it, the viral aspect is limited to the library. In Pharo, that means you can use UFFI to connect to LGPL libraries, and you can probably create plugins. Loading smalltalk libraries that are LGPL is not exactly the same as linking, there is no clear boundary between compile-time and run-time, as everything is in the image. That makes the LGPL difficult to interpret in the smalltalk case, and potentially viral.

+1.

On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hilaire@drgeo.eu> wrote:

...

Regarding porting GPL software, I guess you mean rewriting with Smalltalk, you should be free to license it as you want, for example as MIT. AFAIK there is no evil restriction as "seen the code" under the GPL.

It is not as clean as that. Many consider "seen the code" to implicate "derived code". Whether a court of law agrees with this or not is not what you should consider. The best advice I received from a lawyer is that winning in court (sometimes after years of effort) is still a loss, so you should position yourself so that no one even thinks they can take you court.

...

For library, alternative is LGPL and I read this interesting note: One should note that subclassing a Java (or other OO) class licensed under the LGPL is regarded as a use of an interface of a library comparable to a function call of a library. It is not regarded as a modification of the original class. Therefore the subclass does not fall under the requirements of the LGPL.

The definitive reference of Java + LGPL is https://www.gnu.org/licenses/lgpl-java.en.html which says: "The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries ... The LGPL permits this distribution ... Applications need only follow the requirements in section 6 of the LGPL"

but a Smalltalk Image runs foul of section 6 requiring... "A suitable [shared library] mechanism ... that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable" where an Image is considered to be the "executable".

So incorporating LGPL Smalltalk code into an Image causes all code in the Image to be infected with the LGPL.

...

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

Using LGPL C libraries is fine and doesn't infect your Smalltalk code. Using LGPL Smalltalk libraries does infect all Smalltalk code in your Image. The concern is contributing a bug fixed in Pharo code from an infected image technically infects the whole of Pharo - although you are free to update a clean image with the same bug fix and contribute from there - but thats an awkward process.

...

The only restriction is the receiver should be capable to update the LGPL package independently of the application using the package. Anyway, I don't think you should worried about porting GPL/LGPL libraries as long as your are rewriting it. You can license it under MIT. Then LGPL is also possible.

The term "port" clearly implies "derived" so you cannot arbitrarily re-license just by changing implementation languages. Otherwise for example a GPL library could be relicensed by one team porting from C to Python, then a second independent team ports from Python back to C subverting the original copyright.

=============== Hmmm... actually refreshing myself with the newer license texts just now I notice GPL 3 has added some interesting definitions the GPL 2 lacks...

...

The “Corresponding Source” for a work ... does not include the work's System Libraries

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form.

A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

A “Standard Interface” means an interface that ... is widely used among developers working in that language.

which seems to open the door to a strong argument** that Pharo is such a Major Component protected from even a full GPL3 coded application being loaded and run - i.e. you could fix and contribute Pharo code directly from such an Image - but other non-GPL Smalltalk libraries you mix in may not be similarly protected. But it still seems a grey area with compliance easier to manage using nonCopyLeft licenses.

cheers -ben

** You'd probably want the FSF to directly issue a statement on this.

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? [1] http://shop.oreilly.com/product/0636920036593.do 2017-09-21 17:16 GMT+02:00 Jimmie Houchin <jlhouchin@gmail.com>:

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

I wasn't being cynical when I asked if it makes sense to you the fact that people write free software and give it away for free. I just wanted to know if there's any obvious reason that explains that to you. It's not my intention to judge why proponents of "permissive" licenses think the way they do. My hypothesis is that they see software exclusively as a way to make money. Economists are still obsessed in simplifying human behavior as rules of incentives -> results, until it's become part of our western cultures. It follows that we only act in our own economic interest, and also that nobody would work for free. That's where some people find difficult to explain free software. The same people don't think the end-user's rights to ultimately own the software we provide are valuable. They are consumers before users. Regarding the book, you won't find any direct references to software licenses. I recommend it because it advocates we treat our users differently. Anyway, we agree we disagree. That was never an issue. I wish you a great day too! 2017-09-21 19:36 GMT+02:00 Jimmie Houchin <jlhouchin@gmail.com>:

We will have to agree to disagree.

I have been a passionate user of open source software for over 20 years. Are you really saying that proponents of permissive licenses don't understand why people write free software and give it away for free? Really!

I passionately disagree with the statement of "All software should be GPLd in the first place". This is one of the biggest reasons I passionately dislike the GPL. GPL is goodness and light. All else is evil incarnate. Ugh!

I am not going to defend unethical business practices. But that is not a defense of the GPL or an argument against permissive licenses. I am not a fan Microsoft or Apple, et al. I am a fan FreeBSD and Linux. However I do not believe all closed source or proprietary software is wrong or evil.

I am working my way through the book you suggested. But so far I fail to see where it makes the argument for the GPL and against permissive licenses.

For the record. I am not a professional programmer. All software I am working on if I were to release it (or when) will be under a permissive license, unless it is a port of GPLd software. I am not in the business of software. I am an empowered user. Open source software empowers me more the proprietary software. Permissively licensed software empowers me more than GPLd software**. That is not currently the case for everyone and every situation. One day it we may come closer to that being true. But it takes time. And it takes proper motivation and resources.

**There are many situations that I cannot use GPLd source, but can use permissively licensed source. MIT/BSD empowers where, GPL does not. Here in this community, with this software. GPL is a no go. It is a show stopper. MIT/BSD is welcomed and wanted. Many other communities are likewise.

As I said, we will have to agree to disagree. I doubt that anything above persuades you in any way.

Regardless, I wish you well and have a great day!

Jimmie

On 09/21/2017 10:39 AM, Jose San Leandro wrote:

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?

[1] http://shop.oreilly.com/product/0636920036593.do

2017-09-21 17:16 GMT+02:00 Jimmie Houchin <jlhouchin@gmail.com>:

...

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

From my understanding, GPL is not about "someone else profiting from your work", but to enforce freedom and to accumulate contribution on GPL licensed code. Regarding profit you are free to sell GPL licensed code, publicly or privately to one person or company, your only restriction is to provide the source code too to the recipient. To protect from someone else profiting from your work there are effective variant from the creative commons licenses. Hilaire Le 21/09/2017 à 16:47, Ben Coman a écrit :

* 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]

-- Dr. Geo http://drgeo.eu

2017-09-22 10:27 GMT+02:00 Hilaire <hilaire@drgeo.eu>:

The appropriate and neutral term to describe GPL licence is "recursive".

GPL licence was designed to build a better computing community, where freedom is 1st consideration, even at the expense of a lower acceptance.

And the little technical fact that you can't link code in the Smalltalk world, only create a derivative work, has nothing to do with the community stance on MIT versus GPL. Thierry

Hilaire

Le 20/09/2017 à 21:30, Jimmie Houchin a écrit :

...

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?

-- Dr. Geo http://drgeo.eu

+1 to "recursive" 2017-09-22 11:05 GMT+02:00 Hilaire <hilaire@drgeo.eu>:

I am just stating the neutral term to describe GPL license nature is "recursive", and why it was designed as this. The "viral" term is unnecessary emotionally charged.

I don't fell the discussion turned about MIT vs GPL, Pharo been MIT is just fine.

Hilaire

Le 22/09/2017 à 10:40, Thierry Goubier a écrit :

...

The appropriate and neutral term to describe GPL licence is "recursive".

GPL licence was designed to build a better computing community, where freedom is 1st consideration, even at the expense of a lower acceptance.

And the little technical fact that you can't link code in the Smalltalk world, only create a derivative work, has nothing to do with the community stance on MIT versus GPL.

-- Dr. Geo http://drgeo.eu

On Mon, Sep 25, 2017 at 9:43 PM, Jimmie Houchin <jlhouchin@gmail.com> wrote:

Hello, thanks for the reply.

I have thought about recursive and unfortunately it is not in my opinion an adequate or equivalent substitute. It may be inoffensive, but it is not accurate in conveying those properties or characteristics of the GPL. Something that is recursive generally makes repeated calls to itself. It is neatly contained and does not propagate outside of itself. Calling a recursive method does not make the call chain all the way up to main recursive. The recursive method does its recursion and generally returns its result back to the caller, ending the recursion. The only thing the caller receives is the results, not the recursion.

There are many positive cultural references to something viral or infect(ious). For something to go viral, depends on what that something is. She has an infectious smile, or laugh. Even in biology where we get the term viral. It is not absolutely or always negative. There are things that scientist attempt to use viral characteristics to do good things. Context is everything.

There are no words a GPL proponent could provide which adequately or otherwise describe the viral characteristic of the GPL that would be considered positive by a GPL opponent.

Back to context.

To a GPL proponent, the viral nature of the GPL is considered a positive and good thing. It is the primary reason to choose and use the GPL.

To the GPL opponent, the viral nature of the GPL is considered a negative and bad thing. It is the primary reason to oppose and to avoid using the GPL.

Two side both viewing the same exact thing and understanding it very differently. One positive, one negative. There is no positive spin for this aspect of the GPL for someone wishing to avoid that aspect. No matter what words are chosen.

For the MIT/BSD person we don't necessarily care if you wish to license your software under the GPL. What we care is that your software is expressly and explicitly trying to override our choices and compel us to become GPL. That is what we don't like. The fact that GPL software is GPL software in perpetuity is okay. Just leave us alone. But we know that is not how the GPL works.

A perspective occurred to me this morning. The original author of GPL software is not bound by the GPL.

I think this thread has run its course for now, but just a quick clarification here. The above is only true up until they accept the first contribution from another party - so its not a good argument. cheers -ben .

They have freedoms the GPL takes away. They have the freedom to turn their software into closed source, proprietary software. They have the freedom to not release all of their modifications. They have the freedom to not infect all their other software which may use this otherwise GPLd code. They have freedom to relicense their software. They have many, many freedoms which the GPL removes from everyone who receives the GPLd software. The original author of GPL software has for himself MIT like freedoms.

What we on the MIT/BSD side of things want is for everybody to have all of the freedoms the original author of the software has. People who receive our software maintain all freedoms.

I have seen over the years many GPL licensed projects change to some more permissive license. Once they did so, the success of the project improved. They had greater buy in, and an increase in use. It increased the size of the open source community and an increase in the code base of an open source project. These are good things.

Here I will let it rest. I don't know what else can be expressed to help clarify both sides.

Jimmie

On 09/22/2017 03:27 AM, Hilaire wrote:

...

The appropriate and neutral term to describe GPL licence is "recursive".

GPL licence was designed to build a better computing community, where freedom is 1st consideration, even at the expense of a lower acceptance.

Hilaire

Le 20/09/2017 à 21:30, Jimmie Houchin a écrit :

...

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?

On 20 Sep 2017, at 21:10, Jose San Leandro <jose.sanleandro@osoco.es> 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 <btc@openinworld.com>: On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan@stack.nl> wrote:

...

On 17-09-17 06:59, Jimmie Houchin wrote:

...

And the GPL not be viral in my app provided I only use the GPL library and am not modifying it in my app.

Do I understand this wrong?

Yes. With GPL everything is now GPL. With LGPL, as long as you only link to it, the viral aspect is limited to the library. In Pharo, that means you can use UFFI to connect to LGPL libraries, and you can probably create plugins. Loading smalltalk libraries that are LGPL is not exactly the same as linking, there is no clear boundary between compile-time and run-time, as everything is in the image. That makes the LGPL difficult to interpret in the smalltalk case, and potentially viral.

+1.

On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hilaire@drgeo.eu> wrote:

...

Regarding porting GPL software, I guess you mean rewriting with Smalltalk, you should be free to license it as you want, for example as MIT. AFAIK there is no evil restriction as "seen the code" under the GPL.

It is not as clean as that. Many consider "seen the code" to implicate "derived code". Whether a court of law agrees with this or not is not what you should consider. The best advice I received from a lawyer is that winning in court (sometimes after years of effort) is still a loss, so you should position yourself so that no one even thinks they can take you court.

...

For library, alternative is LGPL and I read this interesting note: One should note that subclassing a Java (or other OO) class licensed under the LGPL is regarded as a use of an interface of a library comparable to a function call of a library. It is not regarded as a modification of the original class. Therefore the subclass does not fall under the requirements of the LGPL.

The definitive reference of Java + LGPL is https://www.gnu.org/licenses/lgpl-java.en.html which says: "The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries ... The LGPL permits this distribution ... Applications need only follow the requirements in section 6 of the LGPL"

but a Smalltalk Image runs foul of section 6 requiring... "A suitable [shared library] mechanism ... that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable" where an Image is considered to be the "executable".

So incorporating LGPL Smalltalk code into an Image causes all code in the Image to be infected with the LGPL.

...

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

Using LGPL C libraries is fine and doesn't infect your Smalltalk code. Using LGPL Smalltalk libraries does infect all Smalltalk code in your Image. The concern is contributing a bug fixed in Pharo code from an infected image technically infects the whole of Pharo - although you are free to update a clean image with the same bug fix and contribute from there - but thats an awkward process.

...

The only restriction is the receiver should be capable to update the LGPL package independently of the application using the package. Anyway, I don't think you should worried about porting GPL/LGPL libraries as long as your are rewriting it. You can license it under MIT. Then LGPL is also possible.

The term "port" clearly implies "derived" so you cannot arbitrarily re-license just by changing implementation languages. Otherwise for example a GPL library could be relicensed by one team porting from C to Python, then a second independent team ports from Python back to C subverting the original copyright.

=============== Hmmm... actually refreshing myself with the newer license texts just now I notice GPL 3 has added some interesting definitions the GPL 2 lacks...

...

The “Corresponding Source” for a work ... does not include the work's System Libraries

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form.

A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

A “Standard Interface” means an interface that ... is widely used among developers working in that language.

which seems to open the door to a strong argument** that Pharo is such a Major Component protected from even a full GPL3 coded application being loaded and run - i.e. you could fix and contribute Pharo code directly from such an Image - but other non-GPL Smalltalk libraries you mix in may not be similarly protected. But it still seems a grey area with compliance easier to manage using nonCopyLeft licenses.

cheers -ben

** You'd probably want the FSF to directly issue a statement on this.

Thanks for the reply and the link. Reasonably informative, but unfortunately not as definitive as one would like. What a mess. Makes me really appreciate the permissive licenses. No headaches. :) I was just curious if that was an option. Fortunately I believe I have alternatives to what I was looking to do. So I can avoid it all together. Someone posted a view by the Racket developers on their understanding of their choice of the LGPL for Racket. It seems that they are switching to MIT/Apache for Racket 7, the next version. They had all contributors sign agreements to the relicensing. https://github.com/racket/racket/issues/1570 https://groups.google.com/forum/#!msg/racket-dev/FiBLEZ-fmn8/8uLTbNamEwAJ Again thanks for the lesson and help. Jimmie On 10/02/2017 01:47 PM, Sven Van Caekenberghe wrote:

...

On 2 Oct 2017, at 19:45, Jimmie Houchin <jlhouchin@gmail.com> wrote:

Back on topic.

To my understanding, if I should port anything GPL licensed that I needed from some language to a C library and licensed it GPL. Then I called my new GPL C library via UFFI. I should have no problems at all. Is that a correct understanding by all?

Does this look like a good approach for most anyone in the Pharo community if they desire to port and use GPL software? https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries

There are different opinions, but I seem to clearly remember the GNU ReadLine case: even though it is a library that you can link to, using it is only allowed by other GPL programs.

...

Thanks.

Jimmie

On 09/15/2017 03:49 PM, Jimmie Houchin 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

No I have not. I don't tend to go their direction very often. I am an advocate of open source software but am not a fan of FSF's ethics or political opinions. And as you say, that want all software to be GPL. Also, I do prefer to hear third party opinions especially those who have potentially court tested ones. That is ultimately where we find the true definition and understanding. Thanks. Jimmie On 10/02/2017 02:48 PM, Peter Uhnák wrote:

But of course this is written by FSF, and for them GPL is not just a legal matter, but an ethical one (and from their perspective GPL being a virus infecting other code is a good comparison, because they really want to take over).

Good and valid questions. Primarily consumer side. I am a longtime user of Linux, 20+ years. I prefer and advocate for open source software even when required to use Windows/Mac. So in general in personal life with friends, family, acquaintances if the subject is computers or software and the opportunity is reasonable I will advocate for open source software. Many times simply as an opportunity to educate people who may not know or be misinformed. I am a business man, an employee of a company. My employer is purely a Windows shop. No development is a part of my day job. All of my use of development software is personal projects. I have not released any software. Nothing has reached a point to release. I am however wanting to release a couple of projects this next year. One I hope to make money off of the use of and not the sale of. The other is personal, not business software. I hope to have both in a releasable state sometime in the next 6 months. My problem has always been indecision on what I thought would be the best language for the project. I have always loved Pharo/Smalltalk. But sometimes I explore other languages. Sometimes because they already have libraries and bindings that would make the project easier. This is still a very reasonable possibility. I am not a professional. I only program in my spare time. Due to my job, sometimes that is very little. Regardless, the software I hope to get to a releasable stage I do plan on releasing as MIT. It is the license I prefer and believe in. One need not program or release software in order to be an advocate. I have no problem with someone writing closed source software. That is their personal or business choice. Myself, I have spent way to much money on software which was closed source and the company disappeared or changed directions. Then I am stuck with software that has no future. Jimmie On 10/02/2017 03:36 PM, Sven Van Caekenberghe wrote:

Jimmie,

Since you started this thread, I have to ask.

You say you are an advocate of open source software. OK. But are you just on the consumer side or also on the producer side ? In other words, have you written/published/supported any non-trivial open source software ?

Are you an academic or are you involved in commercial software (i.e. have you written closed software that you sell or otherwise make money off) ?

Sven

...

On 2 Oct 2017, at 22:06, Jimmie Houchin <jlhouchin@gmail.com> wrote:

No I have not. I don't tend to go their direction very often. I am an advocate of open source software but am not a fan of FSF's ethics or political opinions. And as you say, that want all software to be GPL. Also, I do prefer to hear third party opinions especially those who have potentially court tested ones. That is ultimately where we find the true definition and understanding.

Thanks.

Jimmie

On 10/02/2017 02:48 PM, Peter Uhnák wrote:

...

But of course this is written by FSF, and for them GPL is not just a legal matter, but an ethical one (and from their perspective GPL being a virus infecting other code is a good comparison, because they really want to take over).

On 10/04/2017 03:48 PM, Sven Van Caekenberghe wrote:

...

On 3 Oct 2017, at 06:10, Jimmie Houchin <jlhouchin@gmail.com> wrote:

Good and valid questions.

Primarily consumer side. I am a longtime user of Linux, 20+ years. I prefer and advocate for open source software even when required to use Windows/Mac. So in general in personal life with friends, family, acquaintances if the subject is computers or software and the opportunity is reasonable I will advocate for open source software. Many times simply as an opportunity to educate people who may not know or be misinformed.

I am a business man, an employee of a company. My employer is purely a Windows shop. No development is a part of my day job.

All of my use of development software is personal projects. I have not released any software. Nothing has reached a point to release. I am however wanting to release a couple of projects this next year. One I hope to make money off of the use of and not the sale of. The other is personal, not business software. I hope to have both in a releasable state sometime in the next 6 months.

My problem has always been indecision on what I thought would be the best language for the project. I have always loved Pharo/Smalltalk. But sometimes I explore other languages. Sometimes because they already have libraries and bindings that would make the project easier. This is still a very reasonable possibility. I am not a professional. I only program in my spare time. Due to my job, sometimes that is very little.

Regardless, the software I hope to get to a releasable stage I do plan on releasing as MIT. It is the license I prefer and believe in. One need not program or release software in order to be an advocate.

I have no problem with someone writing closed source software. That is their personal or business choice. Myself, I have spent way to much money on software which was closed source and the company disappeared or changed directions. Then I am stuck with software that has no future. This is a bit my point: if you respect closed-source software and commercial restrictive licenses, you should also respect GPL and friends as valid choices and not describe them with negative adjectives.

On ethical grounds, I like GPL a lot. It is also very successful (Linux, GNU). It is a valid choice. And yes, in certain license constructions that could mean you cannot use certain software.

Regarding negative adjectives. I asked for positive ones that are equivalent to the negative ones. I also demonstrated that the negative ones are quite often used positively in a number of areas beyond software. However, there is no better or even equivalent term for viral or infect(ious). I only brought up this discussion to see if the new Pharo 7 bootstrapping would open up the options to use GPL code. See, I was trying to do something positive with GPL source code. But the GPL license prevents this from happening. And because I respect licenses and laws. I will honor their choice, and their license and completely remove them from the option. I have not seen any way to port GPL software and use it from Pharo. That was my hope for this discussion. GPLv2 and GPLv3 don't even play nice with each other. I respect all choices. I also believe there are consequences for choices made. Anybody can choose to make their software GPL. I also can choose not to view the source of any of it because of the consequences of viewing that source code. Which means ultimately that GPL will have many people like me who opt out of their sources. I respect the right they have to make that choice. They also need to respect mine. We will probably have to agree to disagree on some of the above. I am okay with that. People have different views.

On a more positive note: I personally think that a system like Pharo is the ultimate open source incarnation as you can literally read and change each and every part in the same language (modulo the VM and plugins, but I am on the as-much-in-image as-possible side). I guess very, very few people actually looked inside the Linux kernel, C library or C compiler, let alone a driver, as these are much too complex and too far removed from your own program. In Pharo you can stumble into code in very deep areas such as graphics, the compiler, the debugger, etc ...

I do love your positive note. You have aptly demonstrated your Pharo rock star status. I love everything you have done, even if I don't understand all your code. :)  Maybe when I grow up, I can code like you. (Probably not. And I am not that young. I have children older than half the people here.) This ultimate open source incarnation of Pharo and its ability to find, see, change everything is a thing of beauty. Which is why I have always struggled when I look outside of Pharo and hear the benefits of whatever language. Then I go and try that language. It always drives me back to Pharo. The ability to discover classes and methods that do what you want is the best I have been able to find anywhere. I always struggle with file based languages. What editor is best. (I have never been an Emacs or Vim person.) How do I find the classes and methods I need to use. ... I come running home to Pharo. I think Pharo just keeps getting better. I can't wait for all of the git tools and Pharo 7 bootstrapping to mature. It will be nice. Thanks for engaging in the conversation. Jimmie

Thanks for the reply.  I am not very familiar with compiled code. I just wanted to explore and see if there were any ways that Pharo and GPL sources could work together. The only way I see that can happen is to have your GPL code provide something like a REST API and communicate via networking. Not very friendly for some small situations. Jimmie On 10/04/2017 08:09 AM, Ben Coman wrote:

On Tue, Oct 3, 2017 at 1:45 AM, Jimmie Houchin <jlhouchin@gmail.com <mailto:jlhouchin@gmail.com>> wrote:

Back on topic.

To my understanding, if I should port anything GPL licensed that I needed from some language to a C library and licensed it GPL. Then I called my new GPL C library via UFFI. I should have no problems at all. Is that a correct understanding by all?

Does this look like a good approach for most anyone in the Pharo community if they desire to port and use GPL software?

UFFI is use via "linking", so your C library needs to LGPL to avoid your Smalltalk code needing to be GPL licensed. cheers -ben

Thanks.

Jimmie

On 09/15/2017 03:49 PM, Jimmie Houchin 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