On Wed, Apr 04, 2012 at 12:08:17PM +0200, Miriam Ruiz wrote:
> 2012/4/4 Benj. Mako Hill <m...@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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to