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

[Walter Bender]

meant to Reply-All

-walter


---------- Forwarded message ----------
From: Walter Bender <walter.bender at gmail.com>
Date: Tue, Apr 26, 2011 at 1:24 PM
Subject: Re: [Sugar-devel] [SLOBS] GPL non compliance?
To: Bernie Innocenti <bernie at sugarlabs.org>


On Tue, Apr 26, 2011 at 12:57 PM, Bernie Innocenti <bernie at sugarlabs.org> wrote:
> 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.

Well, I use this impractical way to do all my Sugar development. I
find it much easier than modifying the system libraries.

>
> 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:

It doesn't seem to me that *preferred* form is really an issue in
regard Sugar's Python libraries.

>
>  “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.

I don't interpret the above as a GPLv3 requirement for the ability to
install in a system library. That would seem overly restrictive. But
if so and if we were to switch to GPLv3, then Uruguay would not be
able to use our new releases until the root access problem is resolved
unless one makes a reading of "install" that includes installing in
$HOME. Running from $HOME is not an issue.

>
> 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.

The jhbuild instructions and scripts are well documented in the wiki.

-walter

>
> 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
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



--
Walter Bender
Sugar Labs
http://www.sugarlabs.org



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org