[IAEP] [Sugar-devel] ANNOUNCE: Moving Sugar to GPLv3+
martin.langhoff at gmail.com
Fri Apr 22 10:27:53 EDT 2011
On Thu, Apr 21, 2011 at 6:18 PM, Bernie Innocenti <bernie at sugarlabs.org> wrote:
> The oversight board is considering a motion to upgrade the license of
> Sugar from "GPLv2 or later" to "GPLv3 or later". Before proceeding to a
> vote, we'd like to request feedback from the community.
Interesting. (Bad timing though -- we have a productive pace, can't we
go back to fixing bugs?)
>From the PoV of OLPC-A, this is a mixed bag. The patent wording in v3
is a positive, though nothing ever "protects" you from a broken patent
system. The anti-tivoization clause OTOH is worrying and not
desirable. In any case, v3 is acceptable but not desirable, staying
with v2 is strongly preferred.
Here, I speak with my OLPC-A hat, and from having formally studied
GPLv2 and v3 in two courses in software licensing, masters level, at
Victoria Uni of New Zealand; and reviewed the same licenses with
several lawyers (some specialized in copyright).
As anyone, I may still be misunderstanding some parts; in that case,
it'd be a well-studied mistake.
>From a personal PoV -- those who write/own the code get to say what
happens with it -- and I haven't written more than a dozen lines of
mergeable Sugar code. You won't ever hear me pontificate on other
people's choice of license or sexual orientation.</personal>
One point to note: there isn't copyright assignment to SL so SL does
not own the copyright. So SL can, on its own, relicense as anyone else
could. It may not please some of the authors :-)
> Q: What about sugar-toolkit, which is LGPLv2+?
> A: Following the path of least resistance, every LGPLv2+ module will be
> upgraded to the LGPLv3+.
Worried here about the "least resistance". If SL is going to do this,
I strongly recommend a review of LGPLv3.
FSF licenses aren't all good. I can point to one really good license
with broad appeal -- GPLv2. Other licenses are controversial (GPLv3),
good but confusing (LGPLv2) or downright so-bad-it-should-die (GFDL).
You cannot trust FSF to have crafted a good license. If you are going
to be lazy, be truly lazy and *don't change license*.
> Q: How will the GPLv3+ affect anti-theft systems?
> A: As long as end-users can request and receive developer keys, the
> Bitfrost anti-theft system is compatible with the anti-tivoization
> clause of the GPLv3.
This is... unfortunately not so easy.
My analysis, and I believe it is well reasoned, says that a Sugar
install is not affected by bitfrost in the least. What GPLv3 actually
demands is that the user can modify the source and install (to run)
the modified code -- it only asks for special signing keys or
unlocking keys *if* they are needed for installation of the sw.
On a bitfrost-locked machine, without root access, I can install sugar
and sugar-toolkit in my homedir, and run it from there. Nothing speaks
about replacing the pre-installed binaries.
(Look for references to "installation information" in the text of GPLv3.)
However, I believe that there is disagreement on the above topic.
Unfortunately, there are strong believers in GPLv3 with a different
> Q: How will the GPLv3+ affect OLPC deployments?
> A: Sugar will simply add a few more GPLv3 packages to the ones already
> present in Fedora, so there is no real difference here -- The
> deployments are *already* using GPLv3 software today.
I wish it was *that* simple. From the deployments' PoV, Sugar moving to GPLv3:
- It adds a weak patent protection.
- It opens them to GPLv3 challenges, both warranted, and unwarranted.
Now here's my question -- what the *is* the upside for SugarLabs?
There is a nice group of people being productive at this very moment,
I say let's focus on good code, and feature work... let's not risk a
big fscking flamewar for a change that has no apparent upside.
If anyone is bored of hacking, let's argue about enforcing a mandatory
text editor. I say nano. :-)
martin.langhoff at gmail.com
martin at laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
More information about the IAEP