[IAEP] [SLOBS] [Sugar-devel] GPL non compliance?

Bernie Innocenti bernie at sugarlabs.org
Tue Apr 26 12:57:10 EDT 2011


On Tue, 2011-04-26 at 10:26 -0400, Martin Langhoff wrote:

> > useless because children can install absolutely no additional software
> > packages (they can't do "yum install").
> 
> Um - again you _can_ install sw in your homedir. Not as practical but possible.

It would be quite painful for users. One would have to either rebuild
all of Sugar in jhbuild with prefix set to /home/olpc/sugar, or copy the
code manually from various system directories, then patch it in multiple
places so it would run from this new location. I'd say it's beyond the
ability of a young hacker whose only computer is a locked-down XO-1 with
no way to install additional packages with yum.

The GPL (both v2 and v3) requires that users be given the full source
code in its *preferred* form for making modifications to it. The GPLv3
additionally requires that users be given the means to install and run
modified versions. Quoting the license directly:

  “Installation Information” for a User Product means any methods,
  procedures, authorization keys, or other information required to
  install and execute modified versions of a covered work in that User
  Product from a modified version of its Corresponding Source. The
  information must suffice to ensure that the continued functioning of
  the modified object code is in no case prevented or interfered with
  solely because modification has been made.

My feeling is that, in order to be in compliance, deployments would have
to provide detailed instructions for installing Sugar in the user's
home... or simply give them root access.

Note that Sugar updating its license would simply add yet another
violation to the existing ones: there are currently between 40 and 60
packages covered by the GPLv3 in a typical OLPC OS image, and the number
is going to increase further when we switch to Fedora 14.

-- 
Bernie Innocenti
Sugar Labs Infrastructure Team
http://wiki.sugarlabs.org/go/Infrastructure_Team




More information about the IAEP mailing list