Dual licencing and Squeak ENH policy
saidani at info.unicaen.fr
Mon Jan 19 19:19:10 UTC 2004
I'm about to release new packages on squeakmap and these packages need
to modify some squeak base classes (hence in Squeak-L) in order to
work properly. So if they modify this classes, I guess I have to
release all the packages under the Squeak-L, but I don't want, mainly
because of the exportation clause. So I take a look on several
packages on squeakmap, to get a feeling on what is the common usage, and
I notice two different strategies :
- People who release their contribution on Squeak base classes (in
Squeak-L) in a package different from their main contribution (the
application in MIT Licence or whatever)
- People who don't distinguish between their contribution to the core
of Squeak and their application, and they sometimes choose MIT Licence
or another one, (eg. StarBrowser, Refactoring Browser...) which seems
to me illegal according to the term of Squeak-L
Maybe have we to take care of the way we package, and clearly separate
our contribution to the core project (Squeak Kernel) and our application ?
I don't have a clear understanding of what is a package, module,
plugin and library in Squeak : is this following analogy relevant ?
Linux Kernel (GNU GPL Licence) <-> Squeak Kernel (Squeak-L Licence)
-- Extension (4 kinds)
Package1 (choose one licence) ex: Apache... <-> SqueakPackage1 (choose one) ex: StarBrowser...
Library1 (choose one) ex: libsdl <-> SqueakLibrary1 (choose one) ex:
Plugin1 (choose one) ex: mplayer-plugin <-> SqueakPlugin (choose one)
Module1 (choose one) ex: soundcore <-> "SqueakModule1" (Squeak-L) ex:
almost all extension methods of PackageInfo...
In this case, Module1 could be compiled in the linux kernel or loaded,
and the kernel is said to be tainted if the module licence is not
GNU/GPL. Let us define a SqueakModule as a piece of code modifying the
kernel, i.e. "modifying, replacing, deleting methods of existing
classes objects (the Squeak Kernel/VM) or the existing relationships
of the Squeak Kernel/VM". In the case of Squeak, we have no other
choice than releasing a SqueakModule in Squeak-L. Maybe squeakModule
is a bit confusing term, and could be replaced by squeakEnhancement.
Practically, I release my package under the name MyPackage.st/sar/mcz,
and my enhancements under the name SqueakENH-MyNameOrMyTeam with a
class MyNameOrMyTeamInfo and use the extension facilities
(*mynameorteam-protocole) provided by PackageInfo. The best would be
to automatize this process inside DVS or Monticello.
In this manner, squeak enhancements are directly available on
SqueakMap for squeak users (I find [ENH] announce in squeak-dev list
unusable in a daily practice), and Guides could then decide to
validate this enhancements by including them in SqueakKernel. If not,
a squeak user could even decide to download them from SqueakMap at his
own risk (unstable branch of squeakmap).
In conclusion, it seems to me that dual licencing a
package/library/plugin has no sense since we try to keep the kernel
tiny, self-contained and independent and precedent threads point out
the possible inadequacy of this practice : maybe separating each kind
of contribution could clarify the situation and avoid us dual
NB: I found quite funny and interesting that licence problems force us
to clarify our packaging policy... Our problems help us !
PhD Student in CS / Doctorant en informatique web : http://www.info.unicaen.fr/~saidani
Universite de Caen - Laboratoire GREYC tel : 02-31-56-74-30
Equipe MAD - Campus II - 14032 Caen Cedex fax : 02-31-56-76-30
More information about the Squeak-dev