Hi all!

Wow, this thread is interesting - even if it is not technical.

Sidenote regarding the Disney years, the "work made for hire" explained:
	http://faqs.org/faqs/law/copyright/faq/part3/

The rest of this post is focused on the postings from Andrew - since he
is one of the few of us who really has the answers. :-) So, Andrew - if
you could reply to my questions below I would be most grateful. Well,
others may of course reply too! :-)

Andrew Greenberg wrote:
> Be careful about the suggestion that we can survive well with a 
> Squeak-L main distro and various distributions under other licenses.   
> This probably (almost certainly) isn't so.
>
> Some licenses (Squeak-L and GPL, for example) do not mix, and using one 
> licenses for a distro and another for distributed code, however 
> comforting it may make one feel "technically speaking," is legally a 
> recipe for disaster.

I don't think anyone has proposed that we start creating separate
"wrapper" licenses for "distros". Perhaps one of my postings implied
that but that was never my intention.

SM is just a catalog of packages that you can install. If you argue that
SM shouldn't contain packages under other licenses than Squeak-L then I
would like to know why.

I mean, SM just makes it easier for you to find stuff out there on the
Internet - it hasn't technically changed anything AFAICT - it just makes
everything easier. It's still YOU who press the button and install the
package into your image - just like you could do before by Googling,
downloading, filing-in.

Andrew Greenberg also wrote:
> Until the change is made, however, let us not kill the product (making 
> relicensing wholly unnecessary) by promoting the distribution of 
> software under inconsistent licenses.  That would be foolish in the 
> extreme.

When you say "promoting" I assume you mean that we should not create
"load scripts" or other means of aggregation of packages under possibly
incompatible licenses?

If *this* is your point (and I think it is) I fully agree. Personally I
would be *very* pleased if you could help us setting up some simple
rules about what license combinations are ok (and this is completely
independent of the discussions about possibly moving to something else
than SqL).

The current rule we are following says that everything in "official
Squeak" is under (at least) Squeak-L. In version 3.6 we are going to
start splitting the image into separate packages and the current plan is
to have 3 layers. The names for these layers is an ongoing discussion
(jesus) but let me now just call them "kernel", "coder" and "carnival".
Kernel is the smallest we can get, coder is the minimal development
environment and carnival is (for starters) the thing most corresponding
with the current (3.4) image. Carnival is also for starters considered
to be the "outer border" of "official Squeak".

Now - question 1: Should we stick with the current rule of SqL for
official Squeak (kernel, coder and carnival)? Or are there one or two
other licenses that we could allow for inclusion, like MIT or BSD?

For example - what if say the ArchiveViewer (written by Ned Konz) is
broken out and placed in Carnival (as it will eventually). Ned would
then probably like to change the license to MIT or dual MIT+SqueakL.
Would we still want to have it available under Squeak-L?

Andrew Greenberg wrote:
> I believe that we could survive with a communal understanding to 
> release all of our code under Squeak-L, or a more liberal license, dual 
> licensed with Squeak-L understanding that it gets viraled into Squeak-L 
> when thrust into the image.

The above implies that code must be dual licensed (for example: MIT +
Squeak-L) in order to be ok for inclusion. Right?

Ok, now outside of Carnival there will eventually turn up "distros" in
the form of "load scripts". A load script is simply a package that -
when installed - loads other packages from SM. We could have
classifications of load scripts like, "the script only loads packages
available under":

0. Squeak-L. Period. (would of course allow the dual licensed packages)
1. Squeak-L, MIT, BSD and nothing else. (since these are deemed "ok" to
mix)
2. Any combination of licenses that have been classified as "ok to
install for use but not necessarily anything else".
3. Anything goes - DANGER, warn the user, etc.

Do you think such classifications of the load scripts would be good? The
above list was just something I cobbled together - *if* this is a good
idea, could you help out with creating this list?

Now, for something completely different, possibly changing Squeak-L.
First of all, when Daniel wrote:
> Since what I wish for Squeak is acceptance in the community of free
> software and open source, I think the important issue is DFSG and 
> Debian
> acceptance, not OSI acceptance.

Daniel's use of the word "free" was probably not intended to imply that
we should move towards GPL. I assume. :-) I actually think almost all of
us wants to move towards MIT/BSD and NOT GPL. BSD/MIT are all "accepted"
in the "community of free software" AFAIK.

Secondly I interpreted your postings to mean that it is "smarter" to
first check with Apple to get the license changed instead of crafting a
sublicense and try running with it, even if it is a possibility. :-)
Right?

Regarding your proposals/questions about trying to change Squeak-L:

- It feels reassuring that you don't think revocation is a serious risk.
- Personally I (and I think the majority of the community, but that is a
guess) want BSDish first and Squeakish with minor repairs second. But if
there would be any significant risk in trying to get something BSDish
first then a repaired Squeak-L is always better than nothing.

Since this question has been cropping up regularly with nothing
happening - what would you say is our best bet moving forward? Do you
think we can create this consensus on the list? Should one of us start
to craft a "mission statement" for this activity that we can iteratively
refine on this list until concensus is met? Would you be willing to do
this? Or should Cees or one of the Guides take that moderation role?

Finally, backing up a bit - the reason this discussion began was that
there is a contributor being hesitant about what it means to publish
something "under Squeak-L" and how you actually do it in practice. Could
you perhaps clarify this a bit for us because that is the current *real*
obstacle here? I also think many of us would like to know this too.

regards, Göran