WebClient-Core port to Pharo 1.1 final

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 &euro;/mtl.!*
http://portal.gmx.net/de/go/dsl

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

We do not want a process/system where one single person controls something important.

        - first it does not scale.  
        - second it is not good for the ecosystem feeling.
        - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because
        we could not touched graphics and we needed to integrate other fixes) and we do not want that again.
        - fourth we are reading to share and we know how to do it but not at any price.

Now I have to work. :)

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mon, 30 Aug 2010, Stéphane Ducasse wrote:

> We do not want a process/system where one single person controls something important.
>
> - first it does not scale.
> - second it is not good for the ecosystem feeling.
> - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because
> we could not touched graphics and we needed to integrate other fixes) and we do not want that again.
> - fourth we are reading to share and we know how to do it but not at any price.

It's a bit funny to read that from a "benevolent dictator".


Levente

>
> Now I have to work. :)
>
> Stef
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> We do not want a process/system where one single person controls something important.
>>
>> - first it does not scale.
>> - second it is not good for the ecosystem feeling.
>> - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because
>> we could not touched graphics and we needed to integrate other fixes) and we do not want that again.
>> - fourth we are reading to share and we know how to do it but not at any price.
>
> It's a bit funny to read that from a "benevolent dictator".

I'm happy that this makes you smile.
Apparently you did not study enough history... if we can call that history.

Then you probably do not read not well enough this list because we always discuss and I often do not
have hard thoughts. I'm trying to learn from people and more act as a catalyst. Our process is not close
we just do a simple quality control. Now you can do whatever you want with your software, I will not argue
on that.

Now I prefer to talk with you about software and not things that are too emotional, because I learn
more from it.

Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project