Bug#471927: [Scratch] Scratch 1.4 source code released under GPL v2
On Wed, Apr 04, 2012 at 12:08:17PM +0200, Miriam Ruiz wrote:
> 2012/4/4 Benj. Mako Hill <mako@debian.org>:
> > I also think that the current text describing the trademark license
> > make it clear that re-packaging is fine while using the marks (it
> > says as much) so I don't forsee that this will be a problem getting
> > things into Debian.
>
> Yup, I agree with your POV here. I don't expect big problems from
> ftpmasters, I hope we're right :)
A more fundamental issue could be a potential show stopper. Take a look
at the etoys package -- technically similar, FOSS license, but still in
non-free. Below a full quote from the source package's README.nonfree:
Why is EToys in non-free?
=========================
EToys was rejected from inclusion in the Debian main archive, because the
ftpmasters don't consider the sources as source. ;) Since we unsuccessfully
tried to convince them that EToys belongs into main already and the time until
Lenny will be frozen is short, I decided to upload it to non-free, for the
benefit of the users (so they can simply use apt-get to install etoys, provided
they have non-free in their sources), even though we believe it satisfies all
the requirements of the DFSG [1] and policy [2]. For Lenny+1 we plan to
convince the ftpmasters to accept it in main.
Let me explain the source situation:
EToys comes as an "image", a snapshot of all objects, which
is loaded into a squeakvm, modified in memory, and snapshotted to
an image file again. This image cannot easily be rebuilt from pure source
code, but the snapshots do contain all the source code. The image is
the "preferred form of modification" for the EToys developer community,
this is how they work [3].
The Etoys image is derived from a Squeak image which is derived from a
Smalltalk image back to 1976, when the actual bootstrapping happened. This
is in contrast to how some Lisps work, they do a lengthy bootstrap from
source and then do a memory snapshot so they can skip the initialization
at startup time. To modify that snapshot, one changes the code and rebuilds
the snapshot. But in Smalltalk, to modify the snapshot all the source code
tools "patch" live object memory directly. So we think this kind of source
form is enough to satisfy the DFSG.
Squeak source code in text form can be seen, shared and modified from within
the squeakvm. That's what everybody does with Squeak source code. The changes
are then either available as "change sets" or as "Monticello" packages (a
version control system for Smalltalk code, see [4]), and can be distributed
separatly or used to create derived versions of the modified blobs. But while
this works for small changes, this isn't practical to rebuild a complete image.
[1] http://www.debian.org/social_contract#guidelines
[2] file:///usr/share/doc/debian-policy/policy.html
[3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-May/128753.html
[4] http://www.wiresong.ca/Monticello/
Holger Levsen, 2008-06-13
--
Michael Hanke
http://mih.voxindeserto.de
Reply to: