Why Cuis?

To be clear: I am not arguing against rebasing the trunk on Cuis. I'm just not clear on what we gain by doing so, rather than by continuing to make packages unloadable, and by settling on a mechanism to reload them on demand, while keeping reasonable safeguards in place to make sure they'll work with a particular release.

Andreas, Juan? Care to comment?

I appreciate that Cuis really does keep with the spirit of ST-80, whereas Squeak has seen some design drift in it's use as a research environment.

My biggest concern is: has Cuis seen the same scrutiny that went into Squeak 4.0 with regard to licensing concerns? Have we run this idea past the SFC?

One thing that I do think might be interesting: what might we learn by merging with a fork? I'd hope we might learn a lot about merging forks in. Could come in handy when it comes time to (hopefully) rebase Etoys on Squeak; possibly other things.

In any event, you will have my support to the extent that I'm able to be of service.

On 8/22/2010 2:28 PM, Casey Ransberger wrote:
> To be clear: I am not arguing against rebasing the trunk on Cuis. I'm just not clear on what we gain by doing so, rather than by continuing to make packages unloadable, and by settling on a mechanism to reload them on demand, while keeping reasonable safeguards in place to make sure they'll work with a particular release.
>
> Andreas, Juan? Care to comment?

"Rebasing" is not the goal here. I apologize if that impression was
made, but it's not how I think about this. The goal is to learn whatever
we can from Cuis or any other system in terms of where the modularity
boundaries are, and how we need to restructure Squeak to achieve a
similar level of modularity.

I think what we'll learn is that there "themes" where a particular
pattern or concern is repeatedly applied or addressed, and it is by
identifying such themes that I think we can make real progress. This is
why I am interested in the analysis - I would expect that the sets of
modifications fall into such themes that can be applied in the context
of Squeak.

In the end, the result might be so similar as to be indistinguishable,
but that would be the end result of a series of steps applied to Squeak.
Steps, which I might add, that are there to ensure that we do these as
an actual refactoring [1] instead of vandalizing the code base that
utilizes it.

[1] http://en.wikipedia.org/wiki/Refactoring
Code refactoring is the process of changing a computer program's source
code *without* modifying its external functional behavior in order to
improve some of the nonfunctional attributes of the software. (emphasis
mine)

Cheers,
   - Andreas

>>>>> "Casey" == Casey Ransberger <[hidden email]> writes:

Casey> My biggest concern is: has Cuis seen the same scrutiny that went
Casey> into Squeak 4.0 with regard to licensing concerns? Have we run
Casey> this idea past the SFC?

Since the new Squeak will be a calculatable delta from Squeak 4.1, we
merely need to ensure that any new code complies with the license.  If
some of that comes directly from Cuis, we just need to verify its
pedigree.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On Sun, Aug 22, 2010 at 4:28 PM, Casey Ransberger
<[hidden email]> wrote:
> To be clear: I am not arguing against rebasing the trunk on Cuis. I'm just not clear on what we gain by doing so, rather than by continuing to make packages unloadable, and by settling on a mechanism to reload them on demand, while keeping reasonable safeguards in place to make sure they'll work with a particular release.

Morphic 3?

> My biggest concern is: has Cuis seen the same scrutiny that went into Squeak 4.0 with regard to licensing concerns? Have we run this idea past the SFC?

Ah, good point.  I hope Juan will comment about this.

 - Chris

Dear all

What I have understood so far:

You are talking about learning from the experience of Juan (and
hopefully Pavel as he seems to be back and willing to donate time) to
reapply those changes to the regular Squeak 4.1 trunk.

Is this correct?

--Hannes

On 8/22/10, Chris Muller <[hidden email]> wrote:

Hi Casey,

Casey Ransberger wrote:
> To be clear: I am not arguing against rebasing the trunk on Cuis. I'm just not clear on what we gain by doing so, rather than by continuing to make packages unloadable, and by settling on a mechanism to reload them on demand, while keeping reasonable safeguards in place to make sure they'll work with a particular release.
>
> Andreas, Juan? Care to comment?
>  

I'll let Andreas comment. It is his idea. I just offered to help with my
knowledge of Cuis.

> I appreciate that Cuis really does keep with the spirit of ST-80, whereas Squeak has seen some design drift in it's use as a research environment.
>  

Yes. Well put.

> My biggest concern is: has Cuis seen the same scrutiny that went into Squeak 4.0 with regard to licensing concerns? Have we run this idea past the SFC?
>  

 From http://www.jvuletich.org/Cuis/Index.html :

"License
Cuis is distributed subject to the MIT License, as in
http://www.opensource.org/licenses/mit-license.php . Any contribution
submitted for incorporation into or for distribution with Cuis shall be
presumed subject to the same license.

Portions of Cuis are:
Copyright (c) Xerox Corp. 1981, 1982
Copyright (c) Apple Computer, Inc. 1985-1996
Copyright (c) Contributors to Squeak and Cuis projects. 1997-2010"

This is also included in the Cuis distributions, both in a txt file and
in text in a text editor inside Cuis.

Isn't this clear enough?

The original effort to get rid of the old "Squeak License" was done for
Etoys by VPRI. That experience was later replicated in Pharo, Cuis and
Squeak. (I believe it was done in that order). I removed any non license
clean code from Cuis before naming it "Cuis" and announcing it here.
Therefore, every Cuis release has always been MIT license. I said this
many times from the first time Cuis was published, I never said
otherwise, and nobody ever questioned this. The tools for the code
authorship audit are included in Cuis if you want to run them.

Besides, the code in Cuis is a subset of the code in Squeak after Squeak
was released under MIT, except for additions done exclusively by me. My
agreement to relicense my contributions to Squeak under MIT is filed by
VPRI, together with the rest of such agreements.

Please, don't create FUD for no reason.

> One thing that I do think might be interesting: what might we learn by merging with a fork? I'd hope we might learn a lot about merging forks in. Could come in handy when it comes time to (hopefully) rebase Etoys on Squeak; possibly other things.
>
> In any event, you will have my support to the extent that I'm able to be of service.
>  

Good.

Cheers,
Juan Vuletich

Chris Muller wrote:
> On Sun, Aug 22, 2010 at 4:28 PM, Casey Ransberger
> <[hidden email]> wrote:
>  
>> To be clear: I am not arguing against rebasing the trunk on Cuis. I'm just not clear on what we gain by doing so, rather than by continuing to make packages unloadable, and by settling on a mechanism to reload them on demand, while keeping reasonable safeguards in place to make sure they'll work with a particular release.
>>    
>
> Morphic 3?
>  

Well, not really. Morphic 3 is not part of Cuis, it is a separate
project. Morphic 3 is experimental, Cuis is production quality.

>> My biggest concern is: has Cuis seen the same scrutiny that went into Squeak 4.0 with regard to licensing concerns? Have we run this idea past the SFC?
>>    
>
> Ah, good point.  I hope Juan will comment about this.
>
>  - Chris
>  

I've commented about Cuis being MIT clean in another message (just
minutes ago).

WRT asking SFC, I believe that if we need to ask SFC about doing this,
then we'd also need to ask them about any code we add to Squeak, no
matter how small. I see no difference. Given that Cuis is just a subset
of Squeak with additions made only by me, taking any part of Cuis and
loading it into Squeak, is just considering that to be a contribution of
mine to Squeak. This has already been done with the anti aliased
StrikeFonts (and the machinery to render them), the TextEditors, etc.

Cheers,
Juan Vuletich

Hannes Hirzel wrote:
Yes. That's the idea.

Cheers,
Juan Vuletich

On 8/23/2010 3:49 AM, Hannes Hirzel wrote:
> Dear all
>
> What I have understood so far:
>
> You are talking about learning from the experience of Juan (and
> hopefully Pavel as he seems to be back and willing to donate time) to
> reapply those changes to the regular Squeak 4.1 trunk.
>
> Is this correct?

Yes, that is the idea.

Cheers,
   - Andreas

Portions of Cuis are:
Copyright (c) Xerox Corp. 1981, 1982
Copyright (c) Apple Computer, Inc. 1985-1996
Copyright (c) Contributors to Squeak and Cuis projects. 1997-2010"

This is also included in the Cuis distributions, both in a txt file and in text in a text editor inside Cuis.

Isn't this clear enough?

As day; but a text file and an assertion isn't the same as being license clean. 

Casey Ransberger wrote:
Does this reasoning apply to to any other open source project? I mean,
does Squeak (for instance) offer anything but a text file and an
assertion? Any time you install open source in your machine, do you fell
the need to ask the developers if it is really so? Or you think Cuis is
missing something in this regard? I'm puzzled!

I see. I'd really like to know the source of your concern... Any
computer, for instance, the one you're using right now, no matter if it
runs Linux, Windows or Mac, is filled with open source code, at least in
the form of libraries used by all these OSs themselves. I don't think
you needed to contact the developers of each one of them asking
specifically if the license is really the one that was stated in the
software, or the ancestry of the code. Again, I'm puzzled. Maybe I'm
missing something.

> I think the question that I asked was perfectly reasonable. YMMV.

Thanks,
Juan Vuletich