[Squeakfoundation]re: licensing issues

Mark Mullin squeakfoundation@lists.squeakfoundation.org
Mon, 28 Jan 2002 12:30:45 -0500


Paul Fernhout and others have addressed this issue pretty thoroughly, I'd
just throw out a couple of tactical issues that I think reduce the scope of
the problem.

Licensing is primarily a tool to make sure credit flows where it is due, and
control doesn't evaporate like a summer dew.  People use licensed
technologies because the cost of using the technology is lower than the cost
of solving the problem without using the technology.  This fundamental
reasoning I would argue applies equally to the kid with the overclocked
athalon running linux as it does to a server farm with 1K Sun boxes in it.

Licensed technologies continue to be used because they provide a benefit,
and they need to maintain a certain level of consistency to provide that
benefit.  Without "knowing" that I at least am starting with a squeak image
blessed by a number of specialists, I really don't have a prayer.

I believe that a means for classifying a relevant subset of our potential
community would be;
Condition 1
	Do they modify Squeak ?
	Do they modify classes used by the community at large ?
	Do they modify the underlying system ?
Condition 2
	Do they wrap squeak in their application, or is their application wrapped
in squeak ?

Squeak is an open environment that provides a metaphor that works all the
way to the desktop.  It's fundamentally free, it's really really pretty, and
I have accidentally created a bunch of squeak users myself in the last month
just by showing it to them.  Basically, if you can use excel or a tool of
similar complexity, you can switch to squeak as your desktop.


Unless you're an academic researcher or a dot bomb that still has money,
it's simply not in your best interests to subsume Squeak, i.e. to package
the system inside another application.  You loose a whole mess of leverage,
and the whole idea of interacting with other peoples "components" gets a lot
more problematic.  And you just buried a whole mass of very cryptic oop
engine code in your source tree.  So, if you're a researcher and we're
talking visions of a future computing environment, have at it.  If you're in
the latter case, why don't you be nice and let your investors have your
money back before you loose it all ?  Read the doco on plugins before you
decide to take one of the worlds uglier case statements under your wing as
your own problem.

So I'd argue that
	1) It is right and just for a baseline distribution of squeak to exist,
sanctioned by some type of official organization, and controlled by that
organization.  You can't make something else and call it official and you
can't take the official baseline, call it yours, and then sell it.  Users
that modify public squeak classes for fun need to submit them if they want
them to be official, and maybe those that want to sell commercial classes on
top of squeak could donate ?  In the latter case, the organization should
have the ability to (within scrutinized reason) sell an official "Squeak
Ready" logo to commercial providers. (Right does not neccessarily ==
willingness to do so)

	2) If you wire your application like spagetti into squeak PLATFORM code,
you're nutso.  You've also got a nasty copyright problem, as you do not own
the original work.  Built in primitives do not make you nutso.  Files that
contain your own intellectual property remain that, even if linked
statically or dynamically with squeak.  Distributing them is your own
problem, making them compatible with the baseline release is your problem.
In fact, everything is your problem but the ability to download the latest
blessed sources for platform builds.  (I admit to extreme bias here, I'm
trying to connect a virtual reality engine to squeak, not give it away).

	3) Your sqeak application code remains your own, although a system like
squeak makes protecting the source somewhat problematic.  Changes you make
to public community classes become public community property iff you submit
them for consideration/inclusion in the baseline.  Source-less changes to
public classes will annoy the hell out of many users.

Commercial and non profit users could use this structure to submit
fixes/improvements to the fundamental platform layers and squeak code and
this would benefit both communities.  The general community gets new
improved stuff that someone else paid for, the original creator gets to
foist the continued maintenance and baseline inclusion off on the wider
community.

In conclusion, I feel that Squeak has enough in it to serve as the
encompassing paradigm, i.e. we're not going to be confronting "The
OmegaStore Backup Utility - Scripting powered by Squeak", but I do believe
you could see "The OmegaStore Backup Plugin" for your Squeak desktop.  It is
possible to create an avenue where work from individual elements of the
community can flow back to the community at large, and I think there's
enough here to make the system self sustaining, especially given our labor
costs   :-)

Left for later -  what about the organizations using Squeak as part of a
total hardware solution, i.e. the aforementioned omegastore as a $1M SAN
device using Squeak as the control language ? OK, well if it were tape based
then a squeak iterator would probably be fast enough   :-)

Regards All

Mark/Vibrant 3D