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