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

[Yioryos Asprobounitis]

--- On Thu, 4/28/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: Thursday, April 28, 2011, 6:57 AM
> On Thu, Apr 28, 2011 at 5:12 AM,
> Yioryos Asprobounitis
> <mavrothal at yahoo.com>
> wrote:
> > --- 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
> >>
> >
> >
> >
> 
> I am not sure what you are trying to say. Is there a
> proposal in here
> somewhere? Other than to jettison Bitfrost? I didn't
> understand the
> argument as to why nor how you propose to replace its
> functionality,
> only some of which is geared towards safe places to hack.

I actually said exactly the opposite! 
That bitfrost (or any other possible form of santboxing)  should *not* be open for modification and inactivation by the kids. 
If it was not clear enough, said here again.

> How
> specifically should Sugar be making itself address the
> differing needs
> of children and teachers? Other actionable suggestions?

We are discussing the level of modification that a user can have. Correct?
I already suggested that Sugar, at least the part of it relating to UI and activities ("sucrose" in the taxonomy), could be installed and modified as a non-privileged user. 
As far as I understood, there are not any objections but is technically difficult at the time.
I also suggested that teachers' needs for further access/modifications (in "ribose", "glucose" dependencies and other parts of "starch") could be addressed by something analogous to the developer's key.


Come to think of it, maybe a problem is that not everyone understands the same thing when talking about "Sugar".
A clear definition of which exact packages/components is "Sugar" would help.  
The sugar-shell and everything that depends on it directly or indirectly but not any of the sugar-shell dependencies? Everything in SL's git? other?

According to the taxonomy the "Sugar stack" is everything but the hardware and to a user that does not have access to alternative desktops that's the way it feels. 
But is clearly not in the context we are discussing (or otherwise).

This confusion may greatly contribute to the apparent misunderstanding.

Regards

> 
> thanks,
> 
> -walter
> 
> -- 
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>