[Sugar-devel] GPL non compliance? [Sugar-devel Digest, Vol 30, Issue 66]

[Yioryos Asprobounitis]

--- On Wed, 4/27/11, Walter Bender <walter.bender at gmail.com> wrote:

> From: Walter Bender <walter.bender at gmail.com>
> Subject: Re: [Sugar-devel] GPL non compliance? [Sugar-devel Digest, Vol 30, Issue 66]
> To: "Yioryos Asprobounitis" <mavrothal at yahoo.com>
> Cc: sugar-devel at lists.sugarlabs.org
> Date: Wednesday, April 27, 2011, 10:44 AM
> Please excuse the top posting, but I
> want to comment in general rather
> than try to address individual statements you made.
> 
> I gave a talk at Libreplanet last year that addressed many
> of the
> issues you raise regarding the appropriateness of using
> Free Software
> in education. (It is online somewhere... the link escapes
> me at the
> moment.) In my personal opinion, the goal, beyond providing
> great
> tools to as many children as possible, is to acculturate
> them with the
> principles of Free Software; especially, in keeping with
> the belief
> that learning is not something done to you, but something
> do,
> conveying the message that the tools you use are not black
> boxes, but
> things you can shape yourself. That is not to say that I
> expect
> children to be submitting patches (although a few have),
> but being
> immersed in the freedoms associated with Free Software is
> part of the
> process of achieving technological fluency. We have yet to
> prove that
> this fluency spills over into other aspects of life, but
> that is my
> working hypothesis.
> 
> That said, there are very few examples of Free Software
> that are
> really end-user modifiable in any practical sense except by
> expert end
> users. I made the point at Libreplanet that we need to go
> beyond
> providing theoretical freedoms to providing code that
> really can be
> expected to be modified by the end user. (This is not easy
> to do -- it
> has been one of the issues I have been struggling with
> personally with
> the Sugar Activities I have been maintaining, e.g., Turtle
> Art, where
> I have tried to provide a plurality of ways into the
> code.)
> 
> Can it be done safely? I implore you to reread the Bitfrost
> document,
> which describes how we intended to provide the children
> with a safe
> place to exercise their freedoms. Although not fully
> implemented, the
> goal remains to have a sufficiently robust environment that
> children
> and teachers can experiment and make mistakes without
> harming
> themselves, their computer, or others. I think this is an
> achievable
> goal and one that is still worthwhile pursuing. Sascha's
> work on
> versioning is part of the solution. My recent reiteration
> of the goal
> to make Sugar be *easily* locally (in $HOME) modifiable
> (copy-on-write) is another example.
> 

Sorry if I did not make myself clear.
I’m all for 8-12 year-old kids having a safe environment to experiment, learn and break Sugar as they can.

What I argue is that this should not include bitfrost (or any other santboxing/security infrastructure). 
Even more so, the entire HW and SW the 8-12 year-olds have to work with/on. 
And licensing should not try to impose otherwise. 


> Another, mundane, reason for GPL is to enable local and
> regional
> modifications to Sugar. I don't believe we can support
> Sugar globally
> without enabling that support to be distributed locally.
> But also,
> putting responsibility into the hands of local and
> regional
> organizations goes part and parcel with the acculturation I
> spoke of
> earlier. Unless you feel some ownership, why bother? So we
> want people
> to have the opportunity to invest themselves in the
> project.
> 

It would appear that all downstream, from distro packaging all the way to the end 8-12 year-old users, are viewed in unison. 
I do not think that OLPC or CEIBAL engineers, teachers, and pupils are or can be seen as the same thing. 
They clearly have a distinct role in the educational system and thus may require different access/modification level.
  
I would think that (the mandatory) local support and modification can be achieved easily without the need the 8-12 year-olds to have total control of the machine (see developer’s key or similar). 

Regarding the end users (the young kids), modifying the (sandboxed) Sugar part could achieve as much "ownership sense" without any risks.
Besides, as you said is rather unlikely to start modifying telepathy or cairo. 


> I am not qualified to answer your legal questions regarding
> the
> application of software licenses to minors and I expect the
> answer
> varies from place to place.
> 
> I am also hesitant to reopen the root access question, but
> I think
> that OLPC took great care in designing safeguard to system
> regardless
> of whether or not the user has access to root and given
> that the
> combination of Sugar and Fedora has such a small footprint,
> the
> overhead associated with reflashing a damaged system -- the
> worst-case
> scenario -- is not so onerous. In practice, I am unaware of
> any
> serious issues with root access in any OLPC deployment, but
> I may be
> ignorant of some pandemic of problems such as you
> describe.
> 

Sugar runs almost exclusively  on Fedora XOs for now, but is certainly aiming for a wider HW/OS use. 
Neither XO hardware security systems nor re-installation ease on the specific hardware can serve as justification for 2 (or 20) millions 8-12 year-olds to have totally open machines so they can run Sugar.

> FWIW, as I understand it, the reasons for denying root
> access in
> Uruguay had nothing to do with a concern for the operating
> system. It
> was simply a convenient way for Ceibal to preserve a secret
> on each
> machine that was used for their national WiFi service,
> which they want
> to provide freely to children, but only to children.

This is a valid reason though. 
I could even think cost-related cases that may want DRM too. Like making a list of books available for download from a publisher but within the specific deployment only. 
I do ton think that Sugar use should stop them from providing this resource or force them to purchase the copyright and release the titles as free.

And I will not be surprised if conserns about the core-OS appear. 
Wait till some 6th graders decide in a collaborative project to mount a DoS on their XS server for the fun of it or to postpone an upcoming test ;) 
(this would be interesting actually!)

> 
> This is not about politics. It is not about laptops. It is
> an education project.

Amen!

> 
> regards.
> 
> -walter
> 
> 
> On Wed, Apr 27, 2011 at 9:56 AM, Yioryos Asprobounitis
> <mavrothal at yahoo.com>
> wrote:
> >
> > --- On Tue, 4/26/11, sugar-devel-request at lists.sugarlabs.org
> <sugar-
> >>    3. Re: [SLOBS]  GPL non compliance?
> >
> > First let me apologizes for my previous “loaded”
> post. Well... it was loaded.
> > Hopefully this one is not.
> >
> > So I was wondering  to what extend GPLvX applies to
> Sugar’s target users.
> > The *educationa*l goals of use, study, share and
> modify can be certainly fulfilled in the context of one or
> more activities.
> > But why is it a goal _one_ 8 year-old to be able to
> modify Sugar even if this means that 100.000 8year-olds will
> constantly break Sugar because of that?
> >
> > Clearly there is no precedence of that scale and I
> doubt that when drafting a software license the
> “generic”  8-12year-old was even considered. Not that
> special 8-12year-old that went looking and landed in the
> computer/linux world, but the one that was “dropped” in
> it.
> > Is there any indication that actually GPLvX considered
> use by 8-12 year-olds or even that is consciously
> age-agnostic?
> > Do the license legal points apply/have authority over
>  10-year-olds?
> > Does anyone knows if they where ever tested in a court
> and found valid for kids?
> >
> > But beyond legal terms, is it wise to give unlimited
> access  to the software and hardware because using Sugar
> under GPLvX requires it/is a principle /is a political
> statement?
> > How many would trust their computer with root access
> to a 10 yead-old that never met before?
> > And if you do, would you do the same to the current 2
> and hopefully future 20 million, Sugar users?
> > Specially with passwordless root access and
> selinux/bitfrost not fully implemented, inactivated or
> inactivat-able
> > What about if a malicious adult takes a hold of the
> machine directly or remotely?
> > Who would be responsible for any harm by/towards the
> kids/a third party? The 12-year-olds? The granting agency?
> SL? FSF?
> >
> > There are probably mechanisms around these issues, but
> should an elaborate repair, security, safety, monitoring and
> probably policing system be setup because Sugar’s
> license/principle/political statement, demands 8-12
> year-olds be treated as informed adults?
> >
> > *Should   8-12 year-olds be treated as informed
> adults?*
> >
> > If they are, or even capable of, what about labor,
> military, guns, crime, pornography or even just sharp
> objects and camping out alone?
> > (I do not think that the argument “if you can modify
> the code you are responsible enough” is valid. Any
> 10-year-old can type 3 or 30 commands that a hacker posted
> in a newsgroup and another kid said that “is cool”)
> >
> > Sugar is *not* just as any other Linux software out
> there.
> > Is an educational platform aimed at (early)
> pre-adolescent and adolescent pupils  in the context of an
> educational system.
> > Terms and conditions appropriate for this audience
> should guide its licensing principles and not the other way
> around.
> >
> > I’m not advocating locked systems in general. What
> I’m saying is that the decision to fully unlock a system
> should not be a prerequisite to implement Sugar’s
> license.
> > If SL believes that fulfilling a GPLvX license is a
> major issue for 8-12year-old users, then Sugar should  be
> implemented in a way that its license can be easily and
> fully fulfilled by the non-privileged user.
> >
> > In general though I would think that if Linux is to
> take a hold in early education, should draft a license
> appropriate for this age group  (for example stamp it PG-13
> ;) or “tolerate” the violation.  It is not coincidental
> that so far, I believe, all sugar deployments violate all
> GPL licensing and do not allow their end users to modify the
> bulk of the code in the machines (let’s wait and see when,
> to what extend and how, promises for the opposite will
> materialize)
> >
> >
> > _______________________________________________
> > 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
>