- Pharo-users - lists.pharo.org

Re: [Pharo-users] (no subject)

by Christophe Demarey

> Le 20 sept. 2017 Ã 23:36, Stephan Eggermont <stephan(a)stack.nl> a Ã©crit : > > On 17/09/17 05:21, Sean P. DeNigris wrote: >> demarey wrote >>> Let us know if everything is fine. >> Was this issue [1] fixed: >>> I think I found it. It seems to be a bug in the way Launcher/Pharo unzips >>> the downloaded VM. >>> The symlink libgit2.dylib becomes unlinked and appears as just a regular >>> file. If I delete the >>> Pharo.app and unzip 70.zip (which btw maybe should have been deleted >>> during cleanup after >>> the dl) to ./vms/70, the error disappears! > > With todays bleedingEdge PharoLauncher on mac I was able to download and start 60510. When trying to load GToolKit > > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > > I ran into some problem with libgit2 that I could solve by doing the unzipping of the downloaded vm zipfile with the Archive Utility and replacing the vm (and re-adding the sources). I tried to reproduce the problem with the same configuration without success. It works well. I guess you already downloaded the required VM with a previous version of the launcher (using Pharo unzipping). If you delete this VM and use the launcher to run the image, it should download the VM and uses your system unzip command to extract it.

Sept. 21, 2017

Re: [Pharo-users] (no subject)

by Stephane Ducasse

Christophe which version should we take? Stef On Wed, Sep 20, 2017 at 12:17 PM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Hi Sean, Stephan, > > I just updated the PharoLauncher and it should now work fine for 64-bits images. > I just had time to test it roughly but you can give it a try (https://ci.inria.fr/pharo/view/Launcher/job/Launcher/149/) > > Christophe. > > >> Le 20 sept. 2017 Ã 10:52, stephan <stephan(a)stack.nl> a Ã©crit : >> >> On 20-09-17 08:26, Ben Coman wrote: >> >>> Must be something environmental in lookup paths. Can you reproduce or suggest further investigation I can do? >> >> If I understand it correctly it is a problem with the unzipping. Not handling symlinks and preserving permissions. Is that a plugin problem? >> >> Stephan >> >> > >

Sept. 21, 2017

Re: [Pharo-users] PetitParser Mystery

by PBKResearch

Sean I'm not an expert on PetitParser, but I think I understand what is happening. If I am right, I would expect the parser which fails to also fail, for the same reason, if the input is just 'John Smith' without the 'Jr'. If this is not so, you can disregard the rest of this post. 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. (You can see the code at PPSequenceParser>>#parseOn:) In your case, the second component parser, which is 'middleName optional', succeeds, because 'Smith' could be a middle name. The next component, 'lastName', fails because 'Jr' is not a valid last name, but there is no way for the sequence parser to recall that the previous component had an optional element. So the sequence fails. The only way to cope with this that I can see is to make the options explicit by using the slash, which does show the parser where to backtrack to. This is what your second parser does. You could limit the scope of the backtracking to avoid re-parsing the first name, by writing something like: firstName, ((middleName, lastName)/ lastName), generational optional (I'm not sure whether the innermost parentheses are necessary, but at least they do no harm.) Thinking about this, I wondered how 'optional' could ever be used except at the end of a sequence. I think the answer is that it works if the optional token has a format or structure which identifies it uniquely if it does occur; in this case, the effect of 'optional' is to say 'forget it if it doesn't occur'. In your case, there is nothing to distinguish a middle name from a last name; indeed, I believe in US usage they can be the same - if Jane Smith marries John Doe, can she become Jane Smith Doe? 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. Many people in France would write a surname like yours with a space after the 'De', and probably a lower-case 'd' as well. In Scotland, a suffix like 'Jr' could appear as 'the Younger'. Some people have more than two forenames. Some people have double-barrelled surnames, with or without a hyphen. Those are just a few of the complications I can think of. So good luck! Hope this helps Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sean P. DeNigris Sent: 21 September 2017 03:18 To: pharo-users(a)lists.pharo.org Subject: [Pharo-users] PetitParser Mystery Given: generationalPart := (#space asParser, generational) ==> #second. middleName := (#space asParser, (generational not, abbreviatableToken) ==> #second) ==> #second. lastName := (#space asParser, (generational not, token) ==> #second) ==> #second. and input := 'John Smith Jr'. The following parser fails: abbreviatableToken, middleName optional, lastName, generationalPart optional. But this one succeeds: (abbreviatableToken, middleName, lastName, generationalPart optional) / (abbreviatableToken, nil asParser, lastName, generationalPart optional) They look the same to me. What is the difference? Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 21, 2017

PetitParser Mystery

by Sean P. DeNigris

Given: generationalPart := (#space asParser, generational) ==> #second. middleName := (#space asParser, (generational not, abbreviatableToken) ==> #second) ==> #second. lastName := (#space asParser, (generational not, token) ==> #second) ==> #second. and input := 'John Smith Jr'. The following parser fails: abbreviatableToken, middleName optional, lastName, generationalPart optional. But this one succeeds: (abbreviatableToken, middleName, lastName, generationalPart optional) / (abbreviatableToken, nil asParser, lastName, generationalPart optional) They look the same to me. What is the difference? Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 21, 2017

Re: [Pharo-users] (no subject)

by Stephan Eggermont

On 17/09/17 05:21, Sean P. DeNigris wrote: > demarey wrote >> Let us know if everything is fine. > > Was this issue [1] fixed: >> I think I found it. It seems to be a bug in the way Launcher/Pharo unzips >> the downloaded VM. >> The symlink libgit2.dylib becomes unlinked and appears as just a regular >> file. If I delete the >> Pharo.app and unzip 70.zip (which btw maybe should have been deleted >> during cleanup after >> the dl) to ./vms/70, the error disappears! With todays bleedingEdge PharoLauncher on mac I was able to download and start 60510. When trying to load GToolKit Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. I ran into some problem with libgit2 that I could solve by doing the unzipping of the downloaded vm zipfile with the Archive Utility and replacing the vm (and re-adding the sources). Stephan

Sept. 20, 2017

Re: [Pharo-users] (no subject)

by Stephan Eggermont

On 20/09/17 12:17, Christophe Demarey wrote: > I just updated the PharoLauncher and it should now work fine for 64-bits images. > I just had time to test it roughly but you can give it a try (https://ci.inria.fr/pharo/view/Launcher/job/Launcher/149/) Pharo7 64 bit starts fine on Mac. Good work. Stephan

Sept. 20, 2017

Re: [Pharo-users] Pharo 7 license question

by Jimmie Houchin

Please, feel free to participate. You are not hijacking anything, you are voicing your opinion and participating in the community. This is good. We don't all have to have the same opinion or values. People expressing their opinion is a valuable part of any community. We may agree or disagree, but it helps in understanding each other. Here is how I view this. GPL restricts my rights as a "user" to preserve the rights of the author. I (author) do not want you (user) to use my software in any way that I (author) do not approve of. GPL is viral. It is not viral because of what it wants to preserve. It is viral because in many cases it compels (forces) users to change the license of the software in their system to the GPL. This is why Pharo can not use GPL. Because it would force all of Pharo to become GPL. This is expressly what the authors of the GPL wanted. It is expressly what the authors of Pharo do not want. It is viral because of what it does, how it behaves, what it forces. Not because of what it preserves. The viral nature isn't preserving the original GPL software, but rather infecting somebody else's software. Which is why I asked my question. If I ported GPL software would that license affect anything more than what I wrote. The most common answer was YES. It would affect everything or infect everything. I don't care about a small piece being GPL. I care about how it impacts the bigger piece. You say it defends rights. It just removed my right to license my software how I wish. The only way to preserve that option is to not use GPL software. Now, should I choose to not use GPL software. How has that benefited anybody in the GPL ecosystem? Not at all. We like to talk about the bad big corporation stealing our hard work and our software and making millions of dollars. Yes big corp. prefers MIT/BSD. They also prefer to release their own hard work and dollars as MIT/BSD licensed software. It isn't as if it is all take on big corporation's side. They prefer the permissive license both as author and user. MIT/BSD simply says you the user may do anything you want. Just don't blame me (author) for anything. And give author(s) credit for what they have created. I would rather have people, businesses believe in open source software and use and release open source software because they are believers and not because some license forced them to do so. That is how MIT/BSD software is. And in reality it is how all authors of open source software are regardless of license. They do it because the believe in it. It is wrong to think that MIT authors don't believe in the freedoms of open source software. We do. We want the user to reciprocate because they believe, not because we forced them. You can't force anybody. They always have the choice of choosing something different, or writing it themselves. Enough rambling. Even though we very much disagree. Do not be silent. Participate. We all learn. Jimmie On 09/20/2017 02:57 PM, Jose San Leandro wrote: > Hi, > > I was afraid this would hijack the thread, and didn't want to. > > I don't like these metaphors, and my attempt to answer your question > may be better, or less obvious, but I think "viral" and "infection" > only describe the GPL when your mindset does not care about the > freedoms the GPL tries to preserve. > I'd say "effective against people trying to restrict the rights the > GPL defends" instead of "viral". > The "infection" interpretation comes from the idea that the GPL > restricts freedom, which is a trap. We may be used not to care about > certain rights, or think they are secondary or even worthless. Then, > when the GPL forces us not to restrict those rights, and we still > don't care about what the GPL is trying to protect, we can conclude > the GPL is a dangerous infection that restricts our freedom of choice. > GPL is a mechanism to defend users. Software vendors used to limit > users' rights obviously get their "rights" limited. The GPL does not > respect the right to restrict others' rights. > > Anyway, I'm not here to judge. MIT may be the most convenient license > for Pharo nowadays. I'm not discussing that. I just couldn't remain > silent thinking there's an obvious consensus that GPL is "viral" or an > "infection" and that should be avoided at all costs. > > 2017-09-20 21:30 GMT+02:00 Jimmie Houchin <jlhouchin(a)gmail.com > <mailto:jlhouchin@gmail.com>>: > > Hello, > > As the person who initially used the word viral in this thread, > let me ask you a question. > > Personally I greatly dislike the GPL and variants. I and many > believe viral is what describes that nature of the GPL. However, I > recognize that there are reasonable people who like the GPL and > greatly like that aspect of its license. It is viral and does > infect. It is seen by many people something to avoid, just as one > would avoid a virus or infection. Yes these are negative terms. > > You protest our use of these terms but do not offer alternatives > that you prefer. In the absence of acceptable alternatives that > GPL proponents prefer, then we left to terms that we naturally > gravitate toward using. So let me suggest that when you make your > opinion heard, please include what you would prefer. Otherwise it > doesn't really help you with your expressed desires of us not > using said terminology. > > So my question to you. What words would you use instead of viral > and infection that equally describe that characteristic of the GPL > and variants? > > Thanks. > > Jimmie > > > On 09/20/2017 02:10 PM, Jose San Leandro wrote: >> Nothing to add to the particular question, but I'm writing to >> express how much I disagree when you use adjectives such as >> "viral" or nouns such as "infection" to describe GPL. >> >> I'm a FSF supporter for a long time, and while I'm used to people >> choosing not to use free software licenses for the sake of >> reaching as many business opportunities as possible, I care about >> the ethics behind the free software movement. >> >> I respect people not caring about that fundamental part of the >> Free Software movement, but I cannot remain silent when everybody >> seems to share the same unfortunate interpretation of what the >> GPL is about. >> >> 2017-09-17 18:59 GMT+02:00 Ben Coman <btc(a)openinworld.com >> <mailto:btc@openinworld.com>>: >> >> On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan(a)stack.nl >> <mailto:stephan@stack.nl>> wrote: >> > >> > On 17-09-17 06:59, Jimmie Houchin wrote: >> >> >> >> And the GPL not be viral in my app provided I only use the >> GPL library and am not modifying it in my app. >> >> >> >> Do I understand this wrong? >> > >> > >> > Yes. With GPL everything is now GPL. With LGPL, as long as >> you only link to it, >> > the viral aspect is limited to the library. In Pharo, that >> means you can use UFFI >> > to connect to LGPL libraries, and you can probably create >> plugins. Loading >> > smalltalk libraries that are LGPL is not exactly the same >> as linking, there is >> > no clear boundary between compile-time and run-time, as >> everything is in the image. >> > That makes the LGPL difficult to interpret in the smalltalk >> case, and potentially viral. >> >> +1. >> >> >> On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hilaire(a)drgeo.eu >> <mailto:hilaire@drgeo.eu>> wrote: >> > Regarding porting GPL software, I guess you mean rewriting >> with Smalltalk, >> > you should be free to license it as you want, for example >> as MIT. >> > AFAIK there is no evil restriction as "seen the code" under >> the GPL. >> >> It is not as clean as that.Â Many consider "seen the code" to >> implicate "derived code".Â Whether a court of law agrees with >> this or >> not is not what you should consider.Â Â The best advice I >> received from >> a lawyer is that winning in court (sometimes after years of >> effort) is >> still a loss, so you should position yourself so that no one even >> thinks they can take you court. >> >> >> > For library, alternative is LGPL and I read this >> interesting note: >> > One should note that subclassing a Java (or other OO) class >> licensed under the LGPL is regarded as a use of an interface >> of a library comparable to a function call of a library. It >> is not regarded as a modification of the original class. >> Therefore the subclass does not fall under the requirements >> of the LGPL. >> >> The definitive reference of Java + LGPL is >> https://www.gnu.org/licenses/lgpl-java.en.html >> <https://www.gnu.org/licenses/lgpl-java.en.html> >> which says: "The typical arrangement for Java is that each >> library an >> application uses is distributed as a separate JAR (Java >> Archive) file. >> Applications use Java's âimportâ functionality to access >> classes from >> these libraries ... The LGPL permits this distribution ... >> Applications need only follow the requirements in section 6 >> of the >> LGPL" >> >> but a Smalltalk Image runs foul of section 6 requiring... "A >> suitable >> [shared library] mechanism ... that (1) uses at run time a >> copy of the >> library already present on the user's computer system, rather >> than >> copying library functions into the executable"Â where an Image is >> considered to be the "executable". >> >> So incorporating LGPL Smalltalk code into an Image causes all >> code in >> the Image to be infected with the LGPL. >> >> >> > So using a LGPL library, even extending it, does not force >> the user to be in the GPL family license. >> >> Using LGPL C libraries is fine and doesn't infect your >> Smalltalk code. >> Using LGPL Smalltalk libraries does infect all Smalltalk code >> in your >> Image. The concern is contributing a bug fixed in Pharo code >> from an >> infected image technically infects theÂ whole of Pharo - >> although you >> are free to update a clean image with the same bug fix and >> contribute >> from there - but thats an awkward process. >> >> >> > The only restriction is the receiver should be capable to >> update >> > the LGPL package independently of the application using the >> package. >> > Anyway, I don't think you should worried about porting >> GPL/LGPL libraries as long >> > as your are rewriting it. You can license it under MIT. >> Then LGPL is also possible. >> >> The term "port" clearly implies "derived" so you cannot >> arbitrarily >> re-license just by changing implementation languages. >> Otherwise for >> example a GPL library could be relicensed by one team porting >> from C >> to Python, then a second independent team ports from Python >> back to C >> subverting the original copyright. >> >> >> =============== >> Hmmm... actually refreshing myself with the newer license >> texts just now >> I notice GPL 3 has added some interesting definitions the GPL >> 2 lacks... >> >> >Â The âCorresponding Sourceâ for a work ... does not include >> the work's System Libraries >> > >> > The âSystem Librariesâ of an executable work include >> anything, other than the work as a whole, that >> >Â (a) is included in the normal form of packaging a Major >> Component, >> >Â Â Â but which is not part of that Major Component, and >> >Â (b) serves only to enable use of the work with that Major >> Component, or to implement a >> >Â Â Â Standard Interface for which an implementation is >> available to the public in source code form. >> > >> >Â Â A âMajor Componentâ, in this context, means a major >> essential component >> >Â Â (kernel, window system, and so on) of the specific >> operating system (if any) >> >Â Â on which the executable work runs, or a compiler used to >> produce the work, >> >Â Â or an object code interpreter used to run it. >> > >> > A âStandard Interfaceâ means an interface that >> > ... is widely used among developers working in that language. >> >> which seems to open the door to a strong argument** that >> Pharo is such >> a Major Component protected from even a full GPL3 coded >> application >> being loaded and run - i.e. you could fix and contribute >> Pharo code >> directly from such an Image - but other non-GPL Smalltalk >> libraries >> you mix in may not be similarly protected. But it still seems >> a grey >> area with compliance easier to manage using nonCopyLeft licenses. >> >> cheers -ben >> >> ** You'd probably want the FSF to directly issue a statement >> on this. >> >> > >

Sept. 20, 2017

Re: [Pharo-users] Continued Fractions

by Stephane Ducasse

I wish you a lot of luck on this experience! On Tue, Sep 19, 2017 at 10:51 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I need to match print ads sizes from various publications with a > standardized list of ratios (e.g. 2:1, 1:1, 2:7...) plus a bunch of other > metrics. > > So a rect of 1543@331 gives a float value that has can be best approximated > by a continued fraction approach. > > But there are other complications. Now I am using a lookup table and try to > match with just a distance. > > I am using DataFrame and hopefully more Roassal for all of this. > > Pharo can be a good tool to manage the object model of this problem space. I > am prototyping something. We'll see how far I can get. > > Phil > > On Tue, Sep 19, 2017 at 9:30 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi phil >> >> just out of sane curiosity do you have a pointer on ratio and >> rectangle and continued fraction? >> >> Stef >> >> On Mon, Sep 18, 2017 at 12:40 PM, werner kassens <wkassens(a)libello.com> >> wrote: >> > Hi Phil, >> > yes, in polymath it is the the object PMContinuedFraction. >> > werner >> > >> > >> > On 09/17/2017 08:38 PM, phil(a)highoctane.be wrote: >> > >> > Ah, I see there is something in the Numerical Methods book. :rolleyes: >> > >> > Phil >> > >> > On Sun, Sep 17, 2017 at 8:30 PM, phil(a)highoctane.be <phil(a)highoctane.be> >> > wrote: >> >> >> >> Do we have anything related to continued fractions in Pharo? >> >> >> >> https://en.wikipedia.org/wiki/Continued_fraction >> >> >> >> I need that to match rectanges to aspect ratios etc. >> >> >> >> TIA >> >> Phil >> > >> > >> > >> >> >

Sept. 20, 2017

Re: [Pharo-users] Pharo 7 license question

by Jose San Leandro

Hi, I was afraid this would hijack the thread, and didn't want to. I don't like these metaphors, and my attempt to answer your question may be better, or less obvious, but I think "viral" and "infection" only describe the GPL when your mindset does not care about the freedoms the GPL tries to preserve. I'd say "effective against people trying to restrict the rights the GPL defends" instead of "viral". The "infection" interpretation comes from the idea that the GPL restricts freedom, which is a trap. We may be used not to care about certain rights, or think they are secondary or even worthless. Then, when the GPL forces us not to restrict those rights, and we still don't care about what the GPL is trying to protect, we can conclude the GPL is a dangerous infection that restricts our freedom of choice. GPL is a mechanism to defend users. Software vendors used to limit users' rights obviously get their "rights" limited. The GPL does not respect the right to restrict others' rights. Anyway, I'm not here to judge. MIT may be the most convenient license for Pharo nowadays. I'm not discussing that. I just couldn't remain silent thinking there's an obvious consensus that GPL is "viral" or an "infection" and that should be avoided at all costs. 2017-09-20 21:30 GMT+02:00 Jimmie Houchin <jlhouchin(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. 20, 2017

Re: [Pharo-users] Pharo 7 license question

by Sven Van Caekenberghe

> On 20 Sep 2017, at 21:10, Jose San Leandro <jose.sanleandro(a)osoco.es> wrote: > > Nothing to add to the particular question, but I'm writing to express how much I disagree when you use adjectives such as "viral" or nouns such as "infection" to describe GPL. > > I'm a FSF supporter for a long time, and while I'm used to people choosing not to use free software licenses for the sake of reaching as many business opportunities as possible, I care about the ethics behind the free software movement. > > I respect people not caring about that fundamental part of the Free Software movement, but I cannot remain silent when everybody seems to share the same unfortunate interpretation of what the GPL is about. I agree, well said. On ethical grounds I would certainly choose a modern GPL (like AGPLv3). I want my work to benefit the public and remain like that. The fact that someone can take it and sell it goes against the idea of open source. But for a Smalltalk system aiming to commercial use, MIT is the only way forward. > 2017-09-17 18:59 GMT+02:00 Ben Coman <btc(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. 20, 2017