Daniel Vainsencher wrote:
> ["Alan's lifework"]
> Good, that was the same concern that was bothering me. 
> 
> If that's not the problem, I'll reiterate that the problems we face with
> the current situation are two - 
> 1. IP concerns as a risk (which as Alan has mentioned, it's always a
> risk) 
> 2. DFGS/OSI incompatible license as blocking us from many of the best
> ways of 
>  A. Bringing Squeak to a wider audience
>  B. Bringing more open source hackers to Squeak

I completely agree on the benefits.
I think the SqL is reasonably free but ugly.'
It allows great liberty to those who look past its warts.
But it would be great to do better.

> I think this is a good motivation to go the way Jimmie proposes.

Thanks. :)

> A few comments about the specific steps -
> 
>>1. Form a Foundation which can be the maintainer of a new Squeak license 
>>and copyright holder for code individual or corporations which to assign.
> 
> Agreed. About YAS - I haven't found any description of it's copyright
> holding functions. URL?

I haven't seen much there either other than Perl.
Maybe Randal can elablorate?

How much control does the community chosen board members have over said 
Foundation? Would we be able to seperate into an independent Foundation 
later should we choose?

>>2. Create a new license for the direction we would like Squeak to move. 
>>New code and code with which the copyright holders would like to change 
>>over to.
> 
> Please, let's NOT make a license, but select one. Or many. It could be a
> good idea to select many licenses if we do this prior to some
> negotiation with Apple, in order to keep our options open.

No, no. I didn't mean author YAL.
I would prefer to see the BSD based one I proposed earlier.
Simple, concise, understood, and free. :)

I think if we have 1 and 2 above we can start moving things to the new 
license. I think this would help.

>>3. As we strip the image and move towards SM and the new 3.6+ images, 
>>ascertain ownership of code and work towards relicensing as much code as 
>>possible with the new license.
>>4. Know what code remains under the existing SqL either via Apple or Disney.
> 
> Ok, any concrete suggestions on how we do this?

Well we've had the initials posted on the list. Several authors have 
emailed the list and stated that they granted their permission.

I personally am not expert on this.
What information is available concerning authorship?

As much as possible we should ascertain copyright ownership of code.
What is Apple's, Disney's, otherCorp, individual.

What have we inherited from Apple that was authored and copyrighted by 
Apple? What was authored at Disney?

What was built upon those things by others.
Celeste, PWS, Comanche, games, etc.
These things should cleanly be relicensable by their authors.

How much of the VM is still copyright Apple/Disney?
How significantly has it been re-authored?

>>5. Contact Apple to make effort to relicense, preferably with the new 
>>community license. Disney too, as necessary.

Here is where the due diligence above hopefully benefits us.
Hopefully, the dialogue Cees has engaged in will be fruitful and much of 
this will become a non-issue.

>>6. If relicensing is successful, enjoy.
>>   If not, work towards using Squeak to bootstrap the new community 
>>   licensed version.
> 
> That is, make a new kernel that is able to load the same SM packages.
> This requires

You didn't finish here. ;)

It seems to me that if such becomes necessary. We will have to use 
Squeak to re-author the kernel/core/ui parts of Squeak.
I don't think a clean-room anything regarding Smalltalk can be easily 
done. There is too much knowledge by any Smalltalk community of other 
Smalltalks. Incredible amounts of cross-polination of concepts, ideas 
and implementations. However, to a large extent I think that helps our 
position more than hinders. Similar to the SCO vs. IBM situation.

Will be interesting.

Jimmie Houchin