- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 7 license question

by Offray Vladimir Luna CÃ¡rdenas

Hi, I think that licensing is an important issue and despite of being a pretty political one (a way to express power and empowerment from/to users) is not discussed deeply, so I welcome a lot a friendly thread like this one. I share the views of the free software (which is not the same as open source), but I think that not all software can be released as such. Even the people at FSF provided exceptions like the LGPL as a way to balance practical concerns and liberties. In the case of Pharo, subclassing is the most common way of reusing (instead of linking), the LGPL doesn't work (a long rationality about when/where to use it is on [1] and a interesting analysis is [1a]). [1] https://www.gnu.org/licenses/why-not-lgpl.html [1a] http://giovanni.bajo.it/post/56510184181/is-gpl-still-relevant There are long discussions about how to create cultural (and other) commons and how licensing plays a role on it. The P2P license[2], for example, favors cooperatives instead of private corps (I think that a modification to include small and medium business should be provided). The idea is that license express a world view (about liberty, sharing, reciprocity, diversity, fears, etc.) and we should not overseen that. In my case, what I try to do is to see how a particular license plays a role in creating a commons and making me part of a community that build such commons goods. If I chose a different license for Grafoscopio, instead of MIT, the tool have less probability to be part of the Pharo commons and community (and is not properly a rising star in popularity right now!), but I can express my concerns about diversity in licensing and commons building in other places, like in the Grafoscopio Manual [3]. [2] https://wiki.p2pfoundation.net/Peer_Production_License [3] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/ma… So I think that we should look at how the licenses have enabled or not the building of a common world and who is empowered by such licenses as a complex issue, to balance practical and idealist choices, trying to make them converge. In my case, having Grafoscopio and its documentation and related artifacts licensed as Free Cultural Works [4], has given to me leverage even in negotiations with big entities and they keep such works and derived ones with the same licenses. So, from my personal point of view and practices having such mixtures of licenses have not diminished in any way my own practices in building commons. I would like to explore (networks of) cooperatives and small/medium business as an alternative economical practice to enlarge and protect the commons, but as said, this is a complex issue that requires a lot of field work. Cheers, Offray [4] http://freedomdefined.org/ On 21/09/17 10:39, 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(a)gmail.com > <mailto: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 >> <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 > > >

Sept. 21, 2017

Re: [Pharo-users] Pharo 7 license question

by Jimmie Houchin

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(a)gmail.com > <mailto: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 >> <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 > > >

Sept. 21, 2017

Re: [Pharo-users] (no subject)

by Ben Coman

Could you clarify where to download from? I tried PharoLauncher-user-bleedingEdge-2017.09.20.zip from... https://ci.inria.fr/pharo/view/Launcher/job/Launcher/149/PHARO=61,VERSION=b… with the Pharo-linux-0.2.13.zip I previously downloaded (limited time before bed) cheers -ben On Thu, Sep 21, 2017 at 9:45 PM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi Ben, > > Could you test it with the bleedingEdge version of the launcher to see if > the problem is solved? > > Thanks, > Christophe. > > Le 20 sept. 2017 Ã 08:26, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > > > On Wed, Sep 20, 2017 at 1:12 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> On Thu, Sep 14, 2017 at 8:25 PM, Christophe Demarey < >> christophe.demarey(a)inria.fr> wrote: >> > Hi, >> > >> > I published an update of the Launcher yesterday fixing some issues to >> run >> > Pharo images from Linux. You can find latest-versions (0.2.13) here: >> > http://files.pharo.org/platform/launcher/ >> > It already propose to download Pharo 70 images. The VM is now downloaded >> > automatically if the adequate one is not available. >> > Let us know if everything is fine. >> >> Thanks Christophe for updating PharoLauncher. I'm trying it with Pharo 7 >> images for the first time. >> I hit a problem using Iceberg in downloaded images. >> >> $ unzip Pharo-linux-0.2.13.zip >> $ cd pharo >> $ unzip ../PharoLauncher-user-stable-2017.09.14.zip >> $ ./pharo >> + PharoLauncher > Settings > Enable development environment >> + World > Tools > Iceberg >> ==> iceberg opens okay >> + PharoLauncher > Templates > Pharo 7.0(beta) > latest-32 <Create Image> >> '7latest32' >> + '7latest32' <Launch> >> + World > Tools > Iceberg >> ==> "Error: EXternal module not found" >> >> $ uname -a >> ==> Linux 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 >> GNU/Linux >> >> > but this works okay... > $ curl get.pharo.org/70+vm | bash > $ ./pharo-ui > + World > Tools > Iceberg > ==> iceberg opens okay > > > while this PharoLauncher alternative fails... > $ curl get.pharo.org | bash > $ ./pharo-ui > + World > Tools > Catalog > PharoLauncher <Install stable configuration> > + World > PharoLauncher > ==> Doesn't show Pharo 7 templates > + World > Monticello > ...PharoLauncher/main <Open Repository> > + ConfigurationOfPharoLauncher-ChristopheDemarey.56 <Load> > + World > Playground > "ConfigurationOfPharoLauncher load" <DoIt> > + World > PharoLauncher > Settings > Hard reset persistant state > ==> Pharo 7 templates showing > + '7latest32' <Launch> "i.e. the previously downloaded image" > + World > Tools > Iceberg > ==> "Error: External module not found" > > + World > Monticello... load latest mczs... > * PharoLauncher-Core-ChristopheDemarey.123 > * PharoLauncher-Spec-ChristopheDemarey.51 > + '7latest32' <Launch> "i.e. the previously downloaded image" > ==> "Fetching VM to run Pharo 70 images" > + World > Tools > Iceberg > ==> "Error: External module not found" > > > Version comparison... > > direct get.pharo.org/70+vm > /home/ben/Pharo/adhoc/Pharo7/Pharo.image > Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17 > /home/ben/Pharo/adhoc/Pharo7/pharo-vm/lib/pharo/5.0-201708271955/pharo > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a > Aug 27 2017 > > via PharoLauncher... > /home/ben/Pharo/images/7latest32/7latest32.image > Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17 > /home/ben/Pharo/vms/70-x86/lib/pharo/5.0-201708271955/pharo > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a > Aug 27 2017 > > Must be something environmental in lookup paths. Can you reproduce or > suggest further investigation I can do? > > cheers -ben > > > > > > >

Sept. 21, 2017

Re: [Pharo-users] Pharo 7 license question

by Jose San Leandro

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(a)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 > > >

Sept. 21, 2017

Re: [Pharo-users] Pharo 7 license question

by Herby VojÄÃk

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

Sept. 21, 2017

Re: [Pharo-users] Pharo 7 license question

by Jimmie Houchin

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

Sept. 21, 2017

Re: [Pharo-users] PetitParser Mystery

by Sean P. DeNigris

Peter Kenny wrote > I would expect the parser which fails to also > fail, for the same reason, if the input is just 'John Smith' without the > 'Jr'. Correct! It did. Peter Kenny wrote > The top-level construct in your parser is PPSequenceParser, which works in > a > simple-minded way; it just checks whether each of its component parsers > succeeds. If one of them fails, the whole sequence fails; it does not try > backtracking. Ah, okay. That makes sense. It seems I just got lucky in that when I've done this before, it was the special case you mention below of unique tokens Peter Kenny wrote > firstName, ((middleName, lastName)/ lastName), generational optional That worked for all interesting cases. Peter Kenny wrote > If you are going to produce a parser which copes with all the vagaries of > people's names, especially outside the US, I think you will have some fun. Ha ha, no doubt. I am not presuming to capture the whole domain, just an interesting - and thankfully very limited - subset! Thanks for all the help :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 21, 2017

Re: [Pharo-users] Pharo 7 license question

by Ben Coman

On Thu, Sep 21, 2017 at 3:57 AM, Jose San Leandro <jose.sanleandro(a)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-s… ] 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(a)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(a)openinworld.com>: >> >>> On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan(a)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(a)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. >>> >>> >> >> >

Sept. 21, 2017

Re: [Pharo-users] (no subject)

by Christophe Demarey

Hi Ben, Could you test it with the bleedingEdge version of the launcher to see if the problem is solved? Thanks, Christophe. > Le 20 sept. 2017 Ã 08:26, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > > > On Wed, Sep 20, 2017 at 1:12 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > On Thu, Sep 14, 2017 at 8:25 PM, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > > Hi, > > > > I published an update of the Launcher yesterday fixing some issues to run > > Pharo images from Linux. You can find latest-versions (0.2.13) here: > > http://files.pharo.org/platform/launcher/ <http://files.pharo.org/platform/launcher/> > > It already propose to download Pharo 70 images. The VM is now downloaded > > automatically if the adequate one is not available. > > Let us know if everything is fine. > > Thanks Christophe for updating PharoLauncher. I'm trying it with Pharo 7 images for the first time. > I hit a problem using Iceberg in downloaded images. > > $ unzip Pharo-linux-0.2.13.zip > $ cd pharo > $ unzip ../PharoLauncher-user-stable-2017.09.14.zip > $ ./pharo > + PharoLauncher > Settings > Enable development environment > + World > Tools > Iceberg > ==> iceberg opens okay > + PharoLauncher > Templates > Pharo 7.0(beta) > latest-32 <Create Image> '7latest32' > + '7latest32' <Launch> > + World > Tools > Iceberg > ==> "Error: EXternal module not found" > > $ uname -a > ==> Linux 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 GNU/Linux > > > but this works okay... > $ curl get.pharo.org/70+vm <http://get.pharo.org/70+vm> | bash > $ ./pharo-ui > + World > Tools > Iceberg > ==> iceberg opens okay > > > while this PharoLauncher alternative fails... > $ curl get.pharo.org <http://get.pharo.org/> | bash > $ ./pharo-ui > + World > Tools > Catalog > PharoLauncher <Install stable configuration> > + World > PharoLauncher > ==> Doesn't show Pharo 7 templates > + World > Monticello > ...PharoLauncher/main <Open Repository> > + ConfigurationOfPharoLauncher-ChristopheDemarey.56 <Load> > + World > Playground > "ConfigurationOfPharoLauncher load" <DoIt> > + World > PharoLauncher > Settings > Hard reset persistant state > ==> Pharo 7 templates showing > + '7latest32' <Launch> "i.e. the previously downloaded image" > + World > Tools > Iceberg > ==> "Error: External module not found" > > + World > Monticello... load latest mczs... > * PharoLauncher-Core-ChristopheDemarey.123 > * PharoLauncher-Spec-ChristopheDemarey.51 > + '7latest32' <Launch> "i.e. the previously downloaded image" > ==> "Fetching VM to run Pharo 70 images" > + World > Tools > Iceberg > ==> "Error: External module not found" > > > Version comparison... > > direct get.pharo.org/70+vm <http://get.pharo.org/70+vm> > /home/ben/Pharo/adhoc/Pharo7/Pharo.image > Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17 > /home/ben/Pharo/adhoc/Pharo7/pharo-vm/lib/pharo/5.0-201708271955/pharo > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > > via PharoLauncher... > /home/ben/Pharo/images/7latest32/7latest32.image > Pharo7.0alpha.build.132.sha.4ea2f39a9f43185d31b844be5ad33b677f43bf17 > /home/ben/Pharo/vms/70-x86/lib/pharo/5.0-201708271955/pharo > CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > > Must be something environmental in lookup paths. Can you reproduce or suggest further investigation I can do? > > cheers -ben > > > > >

Sept. 21, 2017

Re: [Pharo-users] (no subject)

by Christophe Demarey

> Le 21 sept. 2017 Ã 13:25, Stephane Ducasse <stepharo.self(a)gmail.com> a Ã©crit : > > Christophe > > which version should we take? For now, the bleeding edge. I will publish a stable as soon as it gets tested enough.

Sept. 21, 2017