Pharo 7 license question
Locked
123
123
 
|
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 |
Re: Pharo 7 license question
|
|
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 > > > |
|
|
> 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. :) |
Re: Pharo 7 license question
|
|
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 |
Re: Pharo 7 license question
|
|
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 >> >> >> |
Re: Pharo 7 license question
|
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: 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 |
|
|
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 |
Re: Pharo 7 license question
|
|
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 |
Re: Pharo 7 license question
|
|
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 |
|
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 |
|
|
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. |
Re: Pharo 7 license question
|
|
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: |
Re: Pharo 7 license question
|
|
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:
|
Re: Pharo 7 license question
|
|
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. > > |
Re: Pharo 7 license question
|
|
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]>:
|
Re: Pharo 7 license question
|
|
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:
|
|
|
In reply to this post by Jose San Leandro
On Thu, Sep 21, 2017 at 3:57 AM, Jose San Leandro <[hidden email]> wrote:
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/]
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.
Sorry to be glib, but viral is a lot simpler (for those of a certain mindset).
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.
cool. cheers -ben
|
Re: Pharo 7 license question
|
|
On 09/21/2017 09:47 AM, Ben Coman wrote:
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 |
|
|
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 |
Re: Pharo 7 license question
|
|
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]>:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |