- Pharo-dev - lists.pharo.org

Re: [Pharo-project] squeaksource no license is dangerous

by StÃ©phane Ducasse

As lukas said we were more in the mood to help people developing software, even private one. Now it may turn out that we were too naive... but this is life :) Stef On Aug 30, 2010, at 1:12 PM, jaayer wrote: > > > ---- On Mon, 30 Aug 2010 03:35:28 -0700 StÃ©phane Ducasse wrote ---- > >> hi guys >> >> after get burned during some years about the license of Squeak. >> What do you think to force people to put a license on projects on squeaksource? >> I have the impression that it would avoid bad situation in the future. >> Even if I could live with it like it is too. This is just that we just wait to get bitten... > > There is an HTML parser on SS with a non-compete clause in its license. There are many other projects on SS that either have no explicit license or are licensed in a non-OSI-approved manner. I have thought of complaining in the past, but nowhere on SS (at least nowhere I could find) does it say that code uploaded to it must be open source; in fact, the site doesn't seem to even mention "open source" at all. If SS is supposed to be the Google Code or Source Forge of the Smalltalk community, only accepting open source code, it should be upfront about it; likewise if it is open to all Smalltalk code, including proprietary. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2010

Re: [Pharo-project] this style looks cool

by StÃ©phane Ducasse

thanks I will check if the inria secretary got it. Stef On Aug 30, 2010, at 11:13 AM, ja(a)anymorphic.com wrote: > > StÃ©phane Ducasse <stephane.ducasse@...> writes: >> did you sign the license agreement? > > For the License, I send a fax to you, now. > I pushed the changes used and created by Anymorphic into Pharo-Inbox > under the Name "Polymorph-Themes-Pro". > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2010

[Pharo-project] Where does an HTTP Client fit in ?

by Sven Van Caekenberghe

Hi, Many valid things have been said from both sides regarding WebClient. As far as I understand it, there are 2 possible 'places' where code can reside: inside Pharo(Core) or outside. The inside code does not have to be compatible with other Squeak/Smalltalks (apart from maybe ANSI and other standards, I am not qualified here). The outside code can choose its compatibility target. Seaside goes very far here, but it hurts to think about the amount of effort that is being put in to achieve this (if it wasn't for the proof of its existence and portability, I would not believe this was even possible) (*) Some other packages might target just one Smalltalk. We cannot demand this from any other, even if it would be a good idea. My question is, where does a (future) HTTP Client fit in ? Both places are possible, one requiring more effort than the other. If I look at what is inside PharoCore, there is an important dependency on HTTP client access at least (Monticello, Updating, Gofer, ...). From that standpoint such a client should be 'inside'. Furthermore, many people have indicated that a good HTTP client (and/or server) is (are) very important today. Any Smalltalk looks silly without a proper HTTP implementation. Even though an 'outside' client (based on Grease for example) would be doable and a good idea, the 'inside' route feels more natural. BTW, In Java both exist (it is in the standard J2SE libs, and there are many clients, like http://hc.apache.org/ ). What do others think ? Sven (*) I respect this very much, it is a remarkable achievement.

Aug. 30, 2010

[Pharo-project] WebClient-Core port to Pharo 1.1 final

by Torsten Bergmann

Before some of us are continue to lament or are too quick in decisions like removing/forking/reimplementing the web lib or judging on all this I think it would be wise to wait for a response from Andreas. First: his response was directly to Sven (with Pharo in CC) and please reread what he wrote: >which are not (or not yet) under MIT. Which means there is a chance that the code will be under MIT. But as he wrote: >that I specifically didn't set a license on WebClient to prevent >such forks without any prior discussion It is fairly reasonable to discuss it first since all our time is limited and the more forks we have the more time may be wasted. A fork would only be necessary if Squeak and Pharo differ too much in the underlying base. Which again leads to the question if it would be possible to reshape both systems onto a common clean kernel ... but thats another story. I think that even a fork of a package would be no problem (you can hardly prevent it when you set something real open source) but there should be a way that contributions/fixes can be folded back into the original (external) code stream. >your repository incorrectly claims that the version of WebClient >in it is LGPLv2. Yes, Sven uploaded a "WebClient-Core-Sven....72.mcz" to squeaksource/ADayAtTheBeach and this repository is LGPLv2. Andreas was just surprised that someone relicensed his code even before he has put a license tag onto the original package. Same for the inclusion into the MIT licensed Pharo core image. On the other hand he published "ConfigurationOfWebClient-ar.1.mcz" into the MIT licensed squeaksource/MetacelloRepository instead of keeping the Configuration into the unlicensed package repository. So it looks like he wanted to do an MIT release ... However: Andreas has to put a license tag onto his code so we can finally stop this whole side discussion and continue to move forward >nobody in Pharo even tries to find out what the license status >for WebClient is. Yes ... looks like there was/is a missing/incomplete process in license checking >In short, my position is that we need more shared libraries, not >more forks +1 >I think WebClient should be an external package External <-> Internal is just a question of a modularized image and loading/unloading. In case of Andreas deciding for MIT and a code integration into the base images (Squeak, Pharo, ...) the community has one leading place for the code (the external package). Similar to what I do for HelpSystem. So Managing the code external is OK since this would allow all us all to load it into own custom images or merge changes into own custom adoptions (if they are necessary). In case Andreas decides for non-MIT there is no option - the community has to find a more open alternative if it wants to include it in Pharo or even port it to other Smalltalk systems (for instance to reuse the code in conjunction with Seaside on VW/VAST/...) My 2cent Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 €/mtl.!* http://portal.gmx.net/de/go/dsl

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Friedrich Dominicus

Levente Uzonyi <leves(a)elte.hu> writes: > On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > >>>> >>>> I suggest that the people that want and know, group together and build an open-source one. >>> >>> Why do you have to have your "own" library? >> >> Did I say "pharo library"? reread carefully I said an "open-source one". > > What I get from Andreas' words is that he's willing to make it open > source if it won't be forked. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Henrik Johansen

On Aug 30, 2010, at 1:06 10PM, Levente Uzonyi wrote: > On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > >>>> >>>> I suggest that the people that want and know, group together and build an open-source one. >>> >>> Why do you have to have your "own" library? >> >> Did I say "pharo library"? reread carefully I said an "open-source one". > > What I get from Andreas' words is that he's willing to make it open source if it won't be forked. So, definitely not MIT then. I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well? > >> We do not want to be in the situation that somebody can change the license under our feet. >> We want a library where people can participate. Now Pharoers will decide, I think that we do not have problem >> with sharing on WebClient. I can understand that people do not like that they cannot improve an infrastructure >> that they will rely upon. We do not want string to number conversion, and rely on squeakToUtf. > > I think Andreas solved these issues with the WebClient-Pharo package, but I may be wrong. If you call overriding String #, (to accept any object responding to asString without raising errors) and Collection #ifEmpty: (to return nil instead of the collection ifNotEmpty) "solving the issues" in Pharo, then yeah, sure. If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes. Personally, I'd call it forcing Squeakisms on anyone wanting to use WebClient, and potentially breaking any number of other packages. The rest I have no problems with, most are fixes/convenience methods which are already in, or should be introduced before Pharo 1.2 (for exampe the SocketStream fixes ) Cheers, Henry

Aug. 30, 2010

Re: [Pharo-project] squeaksource no license is dangerous

by Lukas Renggli

>>after get burned during some years about the license of Squeak. >>What do you think to force people to put a license on projects on squeaksource? >>I have the impression that it would avoid bad situation in the future. >>Even if I could live with it like it is too. This is just that we just wait to get bitten... The problem is that there are thousands of projects without a license. Additionally, since the "License" field was added to SqueakSource relatively late it cannot be easily added anymore. > There is an HTML parser on SS with a non-compete clause in its license. There are many other projects on SS that either have no explicit license or are licensed in a non-OSI-approved manner. I have thought of complaining in the past, but nowhere on SS (at least nowhere I could find) does it say that code uploaded to it must be open source; in fact, the site doesn't seem to even mention "open source" at all. If SS is supposed to be the Google Code or Source Forge of the Smalltalk community, only accepting open source code, it should be upfront about it; likewise if it is open to all Smalltalk code, including proprietary. SqueakSource is more like GitHub. There are various commercial and proprietary projects hosted there, some of them you can't even see as you lack the required permissions. There is no need for code to be open source to store it on SqueakSource. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Lukas Renggli

>> We want a library where people can participate. Now Pharoers will decide, >> I think that we do not have problem >> with sharing on WebClient. I can understand that people do not like that >> they cannot improve an infrastructure >> that they will rely upon. We do not want string to number conversion, and >> rely on squeakToUtf. > > I think Andreas solved these issues with the WebClient-Pharo package, but I > may be wrong. What WebClient-Pharo does is to patch (and break) Pharo in the most absurd ways to make it ill-behaved like Squeak. For example, check out the implementation of String>>#,. Philippe (an expert in writing platform independent code) and Sven have fixed all these issues so that the code works flawlessly on both platforms, Squeak and Pharo. > Well, we are about to use it for Seaside. It scales a lot better than Kom. > Cog can't really speed up Kom (based on our benchmarks done with JMeter)*, > probably because of the heavy use of notifications (DynamicBindings), but it > can boost WebClient significantly. Kom is not ideal, we all know that (thanks for sharing the benchmarks). However, the current licensing situation of WebClient makes it totally useless for me and presumably many other people. Luckily there are many other options. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 30, 2010

Re: [Pharo-project] Magnitude should be reimplemented as a Trait

by jaayer

---- On Mon, 30 Aug 2010 03:32:18 -0700 StÃ©phane Ducasse wrote ---- >+1 >So this is ok :) >What I would love in my wildest dream is to have magnitude using TComparable :) >But this may be too complex. >I would like to have the time to check how we can make trait implementation leaner, smaller..... > >Stef Actually, if you change Magnitude's class definition to this: Object subclass: #Magnitude uses: TComparable instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Numbers' and then manually remove its "comparing" and "testing" messages, everything seems to work. (Same number of passed/failed tests in "KernelTests-Numbers" as before ) But I could see this potentially causing build issues. Also, Magnitude's "testing" messages, despite what their category name implies, do not return booleans; instead they return other Magnitudes. I have recategorized those messages (#min:, #max:, and #min:max:) in TComparable under "comparing" in the attached fileout.

Aug. 30, 2010

Re: [Pharo-project] squeaksource no license is dangerous

by jaayer

---- On Mon, 30 Aug 2010 03:35:28 -0700 StÃ©phane Ducasse wrote ---- >hi guys > >after get burned during some years about the license of Squeak. >What do you think to force people to put a license on projects on squeaksource? >I have the impression that it would avoid bad situation in the future. >Even if I could live with it like it is too. This is just that we just wait to get bitten... There is an HTML parser on SS with a non-compete clause in its license. There are many other projects on SS that either have no explicit license or are licensed in a non-OSI-approved manner. I have thought of complaining in the past, but nowhere on SS (at least nowhere I could find) does it say that code uploaded to it must be open source; in fact, the site doesn't seem to even mention "open source" at all. If SS is supposed to be the Google Code or Source Forge of the Smalltalk community, only accepting open source code, it should be upfront about it; likewise if it is open to all Smalltalk code, including proprietary.

Aug. 30, 2010