- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 7 license question

by Jimmie Houchin

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] ZnHtmlOutputStream Attributes

by Sven Van Caekenberghe

> On 20 Sep 2017, at 20:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Any reason to pass as a flat collection of pairs rather than a collection of > associations or a dictionary? IMHO the former is less intention revealing > and potentially confusingâ¦ I probably did it because it was the least amount of typing. Right now, html tag: #div attributes: #(class menu id one) with: 'Foo'. generates <div class="menu" id="one">Foo</div> Associations would indeed also work, like html tag: #div attributes: { #class->#menu. #id->#one } with: 'Foo'. Since Dictionary>>#do: runs over Associations, a real dictionary would also work then. It is still a bit more to type, but it is clearer. Sven

Sept. 20, 2017

Re: [Pharo-users] Pharo 7 license question

by Jose San Leandro

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

ZnHtmlOutputStream Attributes

by Sean P. DeNigris

Any reason to pass as a flat collection of pairs rather than a collection of associations or a dictionary? IMHO the former is less intention revealing and potentially confusingâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 20, 2017

Call for Participation: SLE 2017 (10th ACM SIGPLAN International Conference on Software Language Engineering)

by Andrei Chis

======================================================================== ** Call for Participation ** 10th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2017) 23-24 October 2017, Vancouver, Canada (Collocated with SPLASH 2017) http://conf.researchr.org/track/sle-2017/sle-2017-papers http://www.sleconf.org/2017 Follow us on twitter: https://twitter.com/sleconf ======================================================================== Software Language Engineering (SLE) is the application of systematic, disciplined, and measurable approaches to the development, use, deployment, and maintenance of software languages. The term "software language" is used broadly, and includes: general-purpose programming languages; domain-specific languages (e.g. BPMN, Simulink, Modelica); modeling and metamodeling languages (e.g. SysML and UML); data models and ontologies (e.g. XML-based and OWL-based languages and vocabularies). ** REGISTRATION ** Friday, 22 September 2017 (Early Registration Deadline) Contact: info(a)splashcon.org http://2017.splashcon.org/attending/registration ** VENUE ** Hyatt Regency Vancouver Hotel reservations: https://2017.splashcon.org/venue/hyattregency ## Program Highlights ### Keynote - Peter D. Mosses Engineering meta-languages for specifying software languages https://conf.researchr.org/track/sle-2017/sle-2017-papers#Keynote-Peter-D-M… ### Awards During the conference, we will announce the following awards: - Distinguished paper. Award for most notable paper, as determined by the PC chairs based on the recommendations of the program committee. - Distinguished reviewer. Award for distinguished reviewer, as determined by the PC chairs using feedback from the authors. - Distinguished artefact. Award for the artifact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artifact evaluation committee. Sponsored by Raincode. ### Accepted Papers - Metacasanova: an optimized meta-compiler for Domain-Specific Languages, Francesco Di Giacomo, Mohamed Abbadi, Agostino Cortesi, Pieter Spronck, Giuseppe Maggiore - Safe Modular Parsing, Haoyuan Zhang, Huang Li, Bruno C. d. S. Oliveira - Concrete Syntax: A Multi-Paradigm Approach, Yentl Van Tendeloo, Simon Van Mierlo, Bart Meyers, Hans Vangheluwe - A Domain-Specific Controlled English Language for Automated Regulatory Compliance, Suman Roychoudhury, Sagar Sunkle, Deepali Kholkar, Vinay Kulkarni - Debugging with Domain-Specific Events, Xiangqi Li, Matthew Flatt - Deep Priority Conflicts in the Wild - A Pilot Study, LuÃs Eduardo de Souza Amorim, Michael J. Steindorfer, Eelco Visser - Comparison of the Expressiveness and Performance of Template-based Code Generation Tools, Lechanceux Luhunu, Eugene Syriani - Incremental Packrat Parsing, Patrick Dubroy, Alessandro Warth - Ensuring Non-interference of Composable Language Extensions, Ted Kaminski, Eric Van Wyk - A Formalisation of Parameterised Reference Attribute Grammars, Scott Buckley, Anthony Sloane - A Symbol-based Extension of Parsing Expression Grammars and Context-Sensitive Packrat Parsing, Kimio Kuramitsu - Structural Model Subtyping with OCL Constraints, Artur Boronat - A Requirements Engineering Approach for Usability-Driven DSL Development, Ankica Barisic, Dominique Blouin, Vasco Amaral, Miguel Goulao - Tool Demonstration: A development environment for the Alf language within the MagicDraw UML tool, Ed Seidewitz - FlowSpec: Declarative Dataflow Analysis Specification, Jeff Smits, Eelco Visser - Robust Programs with Filtered Iterators, Jiasi Shen, Martin Rinard - Energy Efficiency across Programming Languages: How does energy, time, and memory relate?, Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, JÃ¡come Cunha, JoÃ£o Paulo Fernandes, JoÃ£o Saraiva - Concurrent Circular Reference Attribute Grammars, Jesper Ãqvist, GÃ¶rel Hedin - Better Call the Crowd. Using Crowdsourcing to Shape your Domain-Specific Languages, Marco Brambilla, Jordi Cabot, Javier Luis Canovas Izquierdo, Andrea Mauri - Robust Projectional Editing, Friedrich Steimann, Marcus Frenkel, Markus Voelter - Towards a Taxonomy of Grammar Smells, Mats Stijlaart, Vadim Zaytsev - Red Shift: Procedural Shift-Reduce Parsing, Nicolas Laurent - Virtual Textual Model Composition for Supporting Maintenance and Aspect-Orientation, Robert Bill, Patrick Neubauer, Manuel Wimmer - A Chrestomathy of DSL implementations, Simon Schauss, Ralf LÃ¤mmel, Johannes HÃ¤rtel, Marcel Heinz, Kevin Klein, Lukas HÃ¤rtel, Thorsten Berger

Sept. 20, 2017

Re: [Pharo-users] (no subject)

by Christophe Demarey

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. 20, 2017

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

by stephan

On 18-09-17 12:22, laurent wrote: > We try QCMagritte and we enjoy what we see so far. What are the best > practices to glue Magritte and Glorp together ? Especially when you > load-balance requests on several images. Some examples ? > > ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable > version, MADescriptionBuilder missing. For #development versions of > Magritte and QCMagritte, QCConfiguration missing ). So actually I use > the one built on CI. ) I really like describing domain objects with Magritte and using chains of visitors to add cross-cutting concerns like translations, styling and access control. The resulting domain code is very clean and DRY. To map to database/Glorp I would just add properties to the description wherever needed, and add a visitor creating the mappings. We didn't need that as we developed in Pharo and deployed on Gemstone. At the moment QC generates applications using jQuery, and the live updating needs a round-trip to the server. You might want to substitute that with something that does more client side. I haven't looked in detail at what Johan Brichau is doing. An open issue is live updates that update each other. That needs automatically calculating dependencies and update order. I've copied the latest configuration and added #'pharo6.x' but that is not enough. Stephan

Sept. 20, 2017

Re: [Pharo-users] (no subject)

by stephan

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. 20, 2017

Re: [Pharo-users] Smalltalk gets a reference in fastcompany Kay interview

by Bruce O'Neel

Hi, I believe this is the same article: [https://www.fastcompany.com/40435064/what-alan-kay-thinks-about-the-iphone-… which requires no login. cheers bruce > Yes I also used the one time email link or the iPhone app as I don't use Facebook or a google login either. > > Sent from my iPhone > > > On 20 Sep 2017, at 02:54, Holger Freyther wrote: > > > > > >> On 20. Sep 2017, at 06:43, Offray wrote: > > > > Hey! > > > > > > > >> Its a shame nog being able to read the article, because it is not posted in the open web and I don't have Facebook or Google to pay with my privacy for the "privilege" of reading Fast Company. > > > > > > sign-up by email is possible as well, probably with a one time email address? The link is below their google sign-in button. > > > > > > cheers > > holger

Sept. 20, 2017

Re: [Pharo-users] Smalltalk gets a reference in fastcompany Kay interview

by Tim Mackinnon

Yes I also used the one time email link or the iPhone app as I don't use Facebook or a google login either. Sent from my iPhone > On 20 Sep 2017, at 02:54, Holger Freyther <holger(a)freyther.de> wrote: > > >> On 20. Sep 2017, at 06:43, Offray <offray.luna(a)mutabit.com> wrote: > > Hey! > > > >> Its a shame nog being able to read the article, because it is not posted in the open web and I don't have Facebook or Google to pay with my privacy for the "privilege" of reading Fast Company. > > > sign-up by email is possible as well, probably with a one time email address? The link is below their google sign-in button. > > > cheers > holger

Sept. 20, 2017