Re: [Sugar-devel] ANNOUNCE: Moving Sugar to GPLv3+
On Thu, Apr 21, 2011 at 6:18 PM, Bernie Innocenti ber...@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 view. 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. :-) m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Moving Sugar to GPLv3+
Even though I haven't spoken with Bernie about his rationale for proposing the upgrade of the license I would like to explain why I strongly feel that as a member of the SLOBs board and as a representative of the community I have the duty to back the proposal. You see GPL is not only a legality. As Bernie pointed out in a previous email, the GPL is designed to protect user's four freedoms. GPLv3 is only an update to protect users from new forms of abuse (like tivoization). I would really detest to see publishers exploit GPLv2 to provide children with DRM'd books or hardware distributors providing hardware that is unupgradable by the user. In my platform for the board I very clearly stated as my °1 core value that Sugar is Free software because ... it makes explicit the freedom to learn to learn. So I consider it a core part of sugar's mission to defend user's rights to learn to learn and interpret the community's vote as seconding this. Sebastian El 21/04/11 17:18, Bernie Innocenti escribió: 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. In particular, we'd like to know how this change might affect you as a Sugar end-user, distributor, contributor or maintainer. Free Software licensing is a complex topic. To keep the level of the discussion high, please contribute to this thread only after making a small effort to inform yourself. == Questions Answers == Q: what's the benefit of upgrading to the GPLv3? A: The full rationale for the GPLv3 is provided here: http://www.gnu.org/licenses/quick-guide-gplv3.html Q: Do we need to ask the permission of all copyright holders? A: No, we'll take advantage of the or any later version clause in the current license. We're not retroactively re-licensing existing code. Q: How is the actual license change done? A: We need to replace the COPYING file in the source code and update the headers of all source files. This operation can easily be automated. Q: What if the maintainer of a module wants to keep the GPLv2 or later? A: This is is perfectly acceptable, but the combined work comprising GPLv2 and GPLv3 modules would fall under the GPLv3. Q: Are there license compatibility problems with GNOME, Python or other libraries we depend on? A: To the best of our knowledge, all Sugar dependencies are compatible with the GPLv3. Q: When will the change happen? A: We're looking at the 0.94 release cycle. Maintainers of individual activities and non-core projects can update their license at any time, or not at all. Q: What about sugar-toolkit, which is LGPLv2+? A: Following the path of least resistance, every LGPLv2+ module will be upgraded to the LGPLv3+. 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. 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. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ANNOUNCE: Moving Sugar to GPLv3+
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. In particular, we'd like to know how this change might affect you as a Sugar end-user, distributor, contributor or maintainer. Free Software licensing is a complex topic. To keep the level of the discussion high, please contribute to this thread only after making a small effort to inform yourself. == Questions Answers == Q: what's the benefit of upgrading to the GPLv3? A: The full rationale for the GPLv3 is provided here: http://www.gnu.org/licenses/quick-guide-gplv3.html Q: Do we need to ask the permission of all copyright holders? A: No, we'll take advantage of the or any later version clause in the current license. We're not retroactively re-licensing existing code. Q: How is the actual license change done? A: We need to replace the COPYING file in the source code and update the headers of all source files. This operation can easily be automated. Q: What if the maintainer of a module wants to keep the GPLv2 or later? A: This is is perfectly acceptable, but the combined work comprising GPLv2 and GPLv3 modules would fall under the GPLv3. Q: Are there license compatibility problems with GNOME, Python or other libraries we depend on? A: To the best of our knowledge, all Sugar dependencies are compatible with the GPLv3. Q: When will the change happen? A: We're looking at the 0.94 release cycle. Maintainers of individual activities and non-core projects can update their license at any time, or not at all. Q: What about sugar-toolkit, which is LGPLv2+? A: Following the path of least resistance, every LGPLv2+ module will be upgraded to the LGPLv3+. 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. 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. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
