Upgrade license.

[icarito]

In 2011 a referendum was held among the membership of Sugar Labs.

"Based on a sheer count of 1st place votes, v3 received 49% of the vote,
v2 received 29% of the vote, and the apathetic position received the
remaining 22% of the vote."

http://lists.laptop.org/pipermail/devel/2011-July/032529.html
http://lists.laptop.org/pipermail/devel/2011-July/032330.html

[davelab6]

WOW! Nice!

All the code headers need to be changed too before merging, I think

[icarito]

Sorry, thanks for noticing. Done!

[samdroid-apps]

GPLv3+ is a good idea. Stopping Tviosation is great. (Hope that it doesn't conflict with any of the OLPC security things)

But anyway, I don't know much about changing licenses. Don't we need every copyright holder to agree?

[icarito]

I am not a lawyer but I understand from reading GPL2 'or later' header says:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
**(at your option) any later version.**

So it is our option to use any later version of GPL, not a license change but an upgrade.

[davelab6]

Don't we need every copyright holder to agree?

They already did, due to the text that @icarito has quoted.

Hope that it doesn't conflict with any of the OLPC security things

That's an interesting point. @quozl ?

[Cerlyn]

The linked email thread notes that the poll was "non-binding". This implies it was an informal survey to see what people thought and was not a formal vote to change.

That said, it looks like the intent was to allow individual contributors to choose if their modules changed licenses.

A bulk commit therefore might be inappropriate unless the current module maintainer(s) wish it. If this is true, then all RPM/DEB/etc. package specs needs to be updated as well.

With LGPL components, there is the possibility we could break licensing with some programs like Scratch & EToys which interface with Sugar's Journal but not most of the rest of it.

http://lists.sugarlabs.org/archive/iaep/2011-June/013484.html
http://meeting.sugarlabs.org/sugar-meeting/2011-05-08#i_2665773

[icarito]

Note this patch only updates GPL components to v3, it does not touch LGPL components.
Scratch et all remain safe as sugar-toolkit-gtk etc are still LGPL.

Recently Walter declared he thought this change was already done so I thought there were no strong feelings about it.

The intent is to protect user's freedoms, of course :-)

[davelab6]

On 24 April 2016 at 17:23, Samuel Greenfeld notifications@github.com
wrote:

With LGPL components, there is the possibility we could break licensing
with some programs like Scratch & EToys which interface with Sugar's
Journal but not most of the rest of it.

The LGPL allows forming combined works with non-GPL-compatible parts, so
that isn't an issue if the LGPLv3 parts go to LGPLv3.

If they go to GPLv3, then that's actually fine IMHO: Per
http://squeak.org/license/ Squeak is Apache + MIT so, because of Apache,
then actually it is not compatible with GPLv2, but is compatible with GPLv3.

Scratch is also GPLv2-or-later, confirmed in
https://github.com/LLK/Scratch_1.4/blob/master/README#L3 and
https://github.com/LLK/Scratch_1.4/blob/master/LICENSE#L1

[davelab6]

On 24 April 2016 at 17:23, Samuel Greenfeld notifications@github.com
wrote:

A bulk commit therefore might be inappropriate unless the current module
maintainer(s) wish it

That's what the Pull Request process is for; Sebastian is legally able to
offer his fork under the v3 terms, and its now unclear to me what has to
happen for the PR to be merged.

[davelab6]

On 24 April 2016 at 18:45, Sebastian Silva notifications@github.com wrote:

Recently Walter declared he thought this change was already done so I
thought there were no strong feelings about it.

It seems to me a Sugar Labs Member should make a Motion for the next SLOB
Meeting to decide.

[tchx84]

It's been a while since that poll, and there is likely to be a reason why it didn't change back then,so I believe this should at least go trough a SLOBs meeting before we consider changing the license of Sugar.

We need to make sure we understand what exactly it means, for the current people distributing Sugar.

[davelab6]

We need to make sure we understand what exactly it means, for the current people distributing Sugar.

Do you mean the 'deployment' user communities?

[tchx84]

Hi @davelab6, yes, deployments are a good example. I am particularly interested in knowing what is the concrete problem we want to solve by migrating the license, and what could be the problem we would introduce if we did.

I believe we can't take this change lightly, it could be a small patch, but it could have big implications.

I just want to make sure it is clear what these implications are, make them very explicit, so we can communicate them properly to our community and specially to whoever will be affected.

@icarito @walterbender can this topic be discussed during the next SLOB meeting?

[davelab6]

On 24 April 2016 at 23:07, Martin Abente Lahaye notifications@github.com
wrote:

can this topic be discussed during the next SLOB meeting?

I only attended one SLOB meeting, but it seems the monthly IRC meetings
are (or ought to be) for deciding rather than discussing.

I think the implications are all good, and there are no downsides.

There are many concrete problems with the LGPLv2 and GPLv2, which are
solved in v3. Are you familiar with them? If not, please do look them up :)
https://www.google.com/search?q=difference+between+gpl+v2+and+v3

I think for Sugar the #1 concrete improvement that v3 offers is that it
much easier for Sugar distributors to make honest mistakes and recover from
them. Currently with v2, if they mess up compliance with the LGPLv2 or
GPLv2 requirements, they immediately and irrevocably lose their license to
even use the software. This is really bad. But GPLv3 is much more
forgiving.

[tchx84]

I think the implications are all good, and there are no downsides.

There are Sugar deployments (mostly, if not all, via OLPC) who are required to use anti-theft systems. In some cases this means their OS images are cryptographically signed or they don't provide root access. The reasons for why they are required to use these systems differ, but in many cases is not optional for them.

If Sugar migrates to GPLv3, will these deployments still be able to distribute new releases of Sugar with their images? And where exactly could the conflict be? What would be the options for these deployments?

It's always been hard to get the deployments to upgrade to newer versions of Sugar, we have to make sure we are not making it factually impossible by migrating to a different license.

We should at least have answers to these questions before we consider to migrate.

Something else I noticed in the email that Sebastian refers to is that I see an email with numbers for the results of a poll, but the email does not include the meaning of that poll. What does it mean by non-binding? Where it is stated that the migration should happen? In fact, where should that final call come from after all?

[davelab6]

Well the only person at OLPC today who I have managed to speak with is @quozl who seems familiar with the anti theft systems used by OLPC customers and the GPLv2/v3 differences.

If James doesn't respond to this PR discussion within - say - 1 week, then a Sugar Labs Member (ie, someone who can legitimately represent Sugar Labs) will need to approach OLPC to see if they have any objections.

However, I don't foresee any problems with the anti-theft system and the GPLv3 anti-tivoisation requirements: the GPL requires "the user" to be able to upgrade their libre software, and OLPC's customers are legally "the user" (not the children), and OLPC does supply the keys needed to unlock the anti theft system to the legal users if they ask for them.

[quozl]

In our builds now we have these GPLv3 activities;

• TamTam,
• Maze,
• Portfolio,
• Speak,
• Physics,
• Memorize (sic),
• Story,
• Abacus,
• FractionBounce.

There are also packages in Fedora 18, Fedora 20, Ubuntu 14.04 LTS and Ubuntu 16.04 LTS licensed under the GPLv3.

Sugar is not part of our firmware security system.

Therefore, no relicensing obstacle as far as OLPC anti-theft is concerned.

As for what I think of you guys relicensing, I'll keep that to myself.

[davelab6]

Hi James

Thanks for the quick reply! Great to know that GPLv3 is no problem for OLPC
customers.

On 25 April 2016 at 01:16, James Cameron notifications@github.com wrote:

As for what I think of you guys relicensing, I'll keep that to myself.

I would be pleased to learn of any objections :)

Cheers
Dave

[tchx84]

@davelab6 @quozl thanks for the clarifications.

@icarito @walterbender I guess the next step would be to propose this topic for SLOBs to get some sort of decision?

[icarito]

@tchx84 your guess is as good as mine. SLOBS is supposed to do 'oversight' - IMHO this is up to mantainers as the community has already voted. I see no objections raised. As @quozl said, OLPC OS already comes with a bunch of GPLv3 stuff.

[davelab6]

SLOBS is supposed to do 'oversight' - IMHO this is up to maintainers as the community has already voted.

Its still a couple of weeks until the next SLOB meeting, so there's time for objections. I just got my membership made official so I'll make a motion.

[icarito]

This has been approved by SLOBs by 6-0, please merge. Thanks!

[samdroid-apps]

Hello, @icarito.

I gotta do code review, and I don't want to check all the headers. What was the script you used for this? (Also, I need it to run for sugar-toolkit-gtk3, sugar-artwork).

Thanks,
Sam

[icarito]

Hi Sam!

I used a the command rpl - you might have to install it.

I no longer have it in my command line history but, it one long command
like such:
(note the "")

rpl "# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
" "# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>."
* -R

El 04/06/16 a las 07:42, Sam escribió:

Hello, @icarito https://github.com/icarito.

I gotta do code review, and I don't want to check all the headers.
What was the script you used for this? (Also, I need it to run for
sugar-toolkit-gtk3, sugar-artwork).

Thanks,
Sam

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#685 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAMMS2fVhfSNN5CMZ8euXLAg8Y6xP5yXks5qIXKggaJpZM4IOVuJ.