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] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Thu, Apr 21, 2011 at 8:00 PM, Bernie Innocenti ber...@sugarlabs.org wrote: Authors can express their intentions through a license. If you didn't want your code to be redistributed under a later versions of the GPL, then why didn't you distribute as GPLv2-only? On a personal note here... programmers that liked GPLv2 due to its share-and-share-alike quid-pro-quo (like me, perhaps Scott too) trusted FSF for have future versions be bugfix versions. So I've also published GPLv2 bits and now I wish I hadn't. Some things in v3 are bugfixes -- the license compatibility, the patent wording (though it could scare some corporations that do hold patents). But the anti-tivoization clause changes the social contract significantly -- it moves towards a new territory that is problematic. I sure wish that GPLv3 was limited to those bugfixes, and the anti-tivo wording was segregatd to a new license; a bit like some clauses were split off to the Affero-GPL. To me, this seems like the GPv3 has a long list of *practical* advantages over the GPLv2: None of those seem interesting to Sugar. A clearer patent license, no ambiguities for distributors Nice, but GPLv2 is well understood by now. better compatibility with other licenses, A high-profile, well-liked project like Sugar never has problem to get a dual-license grant from any incompat license. I've requested -- and obtained -- such dual-licenses from many (PHP-licensed) projects that we wanted to include in Moodle (GPLv2, and not as high profile as Sugar). anti-tivoization This is rather problematic. While it doesn't affect OLPC/bitfrost, it can affect situations where I'd like to see Sugar in use. For example a well-setup thin-client / terminal server (like SkoleLinux/DebianEdu) may lockdown X so that .xsession is ignored. protection from the DMCA Not relevant. Sugar ain't mplayer. easier path to return into compliance for accidental violations... Nice but... was that ever a problem? There's ample best practice around accidental violations. It doesn't change anything. So my questions are - What's the upside? - At what point do we say hey, this has scant upside, and negative controversy around it, let's spend our time in productive things instead? cheers, 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] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, Apr 22, 2011 at 10:50 AM, Martin Langhoff martin.langh...@gmail.com wrote: - What's the upside? - At what point do we say hey, this has scant upside, and negative controversy around it, let's spend our time in productive things instead? This is the crux of my objection as well. I see Sugar being used as a pawn in some larger argument (about I know not what) and want no part of it. No compelling reason to change license; let's stay as far away from that rathole as possible. People are already free to make a gnewsense of themselves and distribute combined works under GPLv3 terms. Fedora-based distros are arguably doing just that. But going through and changing license information in everyone's source files without their explicit consent (and denying the right to do future distribution under the terms of the GPLv2 *is* a change: GPLv2 or later != GPLv3 or later) -- that's just causing a ruckus for no reason. Please don't start that fight. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, Apr 22, 2011 at 1:00 AM, Bernie Innocenti ber...@sugarlabs.org wrote: On Thu, 2011-04-21 at 18:47 -0400, C. Scott Ananian wrote: On Thu, Apr 21, 2011 at 6:18 PM, Bernie Innocenti ber...@sugarlabs.org wrote: 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. This isn't actually true. You can't change the license on my code -- it's still GPLv2 or later. You can make a combined work where the new parts are GPLv3, and you can redistribute it under the terms of the GPLv3 (because of the or later), but you cannot change the license on the existing code unless you are the sole owner. That is why the FSF does copyright assignment. Isn't this exactly what I wrote? We're not retroactively re-licensing existing code. Really? By moving to GPLv3 your removing the ability to use GPLv2 which is by definition a re-license of the code. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, 2011-04-22 at 16:45 +0100, Peter Robinson wrote: We're not retroactively re-licensing existing code. Really? By moving to GPLv3 your removing the ability to use GPLv2 which is by definition a re-license of the code. Not really, this is a common misconception: redistributing code under later versions of the GPL is explicitly allowed by the current licensing terms (GPLv2 or later). If it weren't the case, then we'd have to ask for permissions to all copyright holders, which includes present and past contributors of legally relevant portions of the code. What constitutes a legally relevant portion is a matter of infinite arguments between copyright lawyers. -- 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
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, Apr 22, 2011 at 12:33 PM, Bernie Innocenti ber...@sugarlabs.org wrote: On Fri, 2011-04-22 at 16:45 +0100, Peter Robinson wrote: We're not retroactively re-licensing existing code. Really? By moving to GPLv3 your removing the ability to use GPLv2 which is by definition a re-license of the code. Not really, this is a common misconception: redistributing code under later versions of the GPL is explicitly allowed by the current licensing terms (GPLv2 or later). If it weren't the case, then we'd have to ask for permissions to all copyright holders, which includes present and past contributors of legally relevant portions of the code. What constitutes a legally relevant portion is a matter of infinite arguments between copyright lawyers. Yes, you seem to be confused Bernie. You can redistribute under a license however you like, usually without explicitly stating it. But if you alter the source files or replace COPYING, you are *changing the license*. That is a different act. A more passive-aggressive means to your end might be to announce that SugarLabs will only accept new contributions which are licensed GPLv3+. That will effect the redistribution change you want, while still (a) pissing off parts of the community, and (b) not illegally altering the license on code you do not own. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, Apr 22, 2011 at 12:54 PM, C. Scott Ananian csc...@laptop.org wrote: Yes, you seem to be confused Bernie. You can redistribute under a license however you like, usually without explicitly stating it. But if you alter the source files or replace COPYING, you are *changing the license*. That is a different act. You are right but in practice in this case there isn't much difference. Anybody, following GPLv2, can just redistribute it under GPLv3, and you *could* track each file as to GPLv2, v3, or mixed. But that would be a lot of bureaucracy that wouldn't help anyone -- anybody interested in GPLv2 sources should just go to the last commit or release under v2. A more passive-aggressive means to your end might be to announce that SugarLabs will only accept new contributions which are licensed GPLv3+. That will effect the redistribution change you want, while still (a) pissing off parts of the community, and (b) not illegally altering the license on code you do not own. Honestly, option b is rather annoying if relevant authors/owners of the copyright aren't in agreement. But it has notthing illegal. The copyright lines are advisory only, and nonbinding. Of course, courts look unfavourably upon knowing infringers that remove (as upon anyone found hiding evidence) them but they aren't sacred in the normal course of things. cheers, 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] Lego WeDo + TurtleArt - Screenshot Code!
Hello My name is Safoura and in my search for a solution to replace the Lego Wedo software with some thing written by myself, I came across this post. I didn't know any thing about sugar labs; seems quiet impressive. I studied the pyhton code a bit but I am not very much familar with python. Do you think there is possibley a way to do similar thing in Java. For some reason , I was not able to find any thing related to the topic of interacting with WEDO using selfwritten programs. I would appreciate your time very very much. Thanks Cheers Safoura ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] TESTING Fedora-15-Nightly-20110421.22-i686-Live-soas.iso and Fedora-15-Nightly-20110421.22-i686-Live-desktop.iso with sugar-emulator
Link to tests on wiki: http://wiki.sugarlabs.org/go/Community/Distributions/Fedora-SoaS#Fedora-15-Nightly-20110421.22-i686-Live-desktop.iso ===Fedora-15-Nightly-20110421.22-i686-Live-desktop.iso=== *Install sugar-desktop: : yum install @sugar-desktop sugar-emulator *sugar-emulator and sugar(from gdm) DO NOT START: -terminal in gnome3-shell $ sugar-emulator GNOME_KEYRING_CONTROL=/tmp/keyring-O85kOR GNOME_KEYRING_PID=1846 ** Message: pygobject_register_sinkfunc is deprecated (HippoCanvasBox) Window manager warning: Fatal IO error 11 (Resource temporarily unavailable) on display ':30'. $ -- This has worked in previous nightly composes Tom Gilliard satellit on #sugar freenode IRC ===Fedora-15-Nightly-20110421.22-i686-Live-soas.iso=== *http://alt.fedoraproject.org/pub/alt/nightly-composes/current.html INSTALL TEST livinst to 4GB USB from Booted CD Custom Install: /boot 500 ext4 / 3400 ext4 rest of usb (no swap) :USB boots to firstboot; user; smolt; gdm other *Does not connect to Wireless AP in f1 neighborhood :no connect dialog to enter AP Key ;Wired connection works ::sees 3 Wireless AP and 3 ad-hoc network points *Central Avitar disappears then chat icon missing on f1 *Restart shuts down system (it us usually goes back to login gdm screen like Control Panel restart does. *logout returns to gdm (still other) browse-120 does not start surf-115.xo does not start ;On shutdown and restart jabber connection is NOT restored. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Csnd] ALSA MIDI output causes segmentation fault
Don't know if this is related or not, but under the latest nightly development versions of Sugar (0.92) and Fedora 15 (Linux), I get an error message with MIDI and this specification: -+rtmidi=alsa -M hw:1,0 The specification works fine with earlier versions of Sugar and Fedora. Strangely, Sugar 0.92 on the XO-1 (upgraded with Fedora 14 or earlier?) doesn't give the error. The error specifically says it can't find the MIDI device (whose number is correct). I've asked Peter Robinson (of SoaS development) to try to track down this issue. So far, no luck. Art Hunkins - Original Message - From: Chuckk Hubbard badmuthahubb...@gmail.com To: Csound List cso...@lists.bath.ac.uk Sent: Friday, April 22, 2011 3:40 PM Subject: [Csnd] ALSA MIDI output causes segmentation fault Hi everyone. For some reason, on Debian Linux testing, with Csound 5.12 (both my own compiled version and the Debian repository version), I get a segmentation fault with this .csd. If I comment out the ALSA MIDI line and uncomment the portmidi line, it works as expected. Does anyone else get this behavior? If not, any ideas why I would? Thanks. -Chuckk -- http://www.badmuthahubbard.com Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sy...@lists.bath.ac.uk with body unsubscribe csound ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
On Fri, Apr 22, 2011 at 7:05 PM, Martin Langhoff martin.langh...@gmail.comwrote: On Fri, Apr 22, 2011 at 12:54 PM, C. Scott Ananian csc...@laptop.org wrote: Yes, you seem to be confused Bernie. You can redistribute under a license however you like, usually without explicitly stating it. But if you alter the source files or replace COPYING, you are *changing the license*. That is a different act. You are right but in practice in this case there isn't much difference. Anybody, following GPLv2, can just redistribute it under GPLv3, and you *could* track each file as to GPLv2, v3, or mixed. But that would be a lot of bureaucracy that wouldn't help anyone -- anybody interested in GPLv2 sources should just go to the last commit or release under v2. A more passive-aggressive means to your end might be to announce that SugarLabs will only accept new contributions which are licensed GPLv3+. That will effect the redistribution change you want, while still (a) pissing off parts of the community, and (b) not illegally altering the license on code you do not own. Honestly, option b is rather annoying if relevant authors/owners of the copyright aren't in agreement. But it has notthing illegal. The copyright lines are advisory only, and nonbinding. Of course, courts look unfavourably upon knowing infringers that remove (as upon anyone found hiding evidence) them but they aren't sacred in the normal course of things. Before this thread ends up something that only copyright lawyers really understand I'd like to take a step back and ask what the SLOB's rationale behind the proposed motion to move from GPLv2 to GPLv3 is? In other words: What specific advantages does GPLv3 offer for Sugar, its community and the individuals, groups, and organizations/deployments using it? Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
Disclaimer: given where I work now, advocating in favor of the GPL will probably makes me look partisan, but long-time friends like you should known that these have been my personal opinions for a long time. On Fri, 2011-04-22 at 10:50 -0400, Martin Langhoff wrote: On Thu, Apr 21, 2011 at 8:00 PM, Bernie Innocenti ber...@sugarlabs.org wrote: Authors can express their intentions through a license. If you didn't want your code to be redistributed under a later versions of the GPL, then why didn't you distribute as GPLv2-only? On a personal note here... programmers that liked GPLv2 due to its share-and-share-alike quid-pro-quo (like me, perhaps Scott too) trusted FSF for have future versions be bugfix versions. So I've also published GPLv2 bits and now I wish I hadn't. Some things in v3 are bugfixes -- the license compatibility, the patent wording (though it could scare some corporations that do hold patents). But the anti-tivoization clause changes the social contract significantly -- it moves towards a new territory that is problematic. I sure wish that GPLv3 was limited to those bugfixes, and the anti-tivo wording was segregatd to a new license; a bit like some clauses were split off to the Affero-GPL. The GPL always has been about protecting the famous Four Freedoms. Back when the GPLv2 was created, nobody had yet figured out that tivoization could be used to game the license and effectively deny users the freedom to modify the software. The GPLv3 merely fixes an unforeseen loophole, additionally protecting users from the DMCA and similar laws that make it illegal to modify free software to get rid of DRM. anti-tivoization This is rather problematic. While it doesn't affect OLPC/bitfrost, it can affect situations where I'd like to see Sugar in use. For example a well-setup thin-client / terminal server (like SkoleLinux/DebianEdu) may lockdown X so that .xsession is ignored. This is actually a case in which the GPLv2 was ambiguous on what it means to distribute the software, whereas the GPLv3 explicitly excludes your particular scenario: To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. There's even explicit wording allowing employers to have workers or contractors use GPL'd software without automatically transferring them any rights: Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. See? It's the other way around: the GPLv3 grants you full permission to lock-down your own thin-clients. protection from the DMCA Not relevant. Sugar ain't mplayer. A few years ago, a large American publisher of schoolbooks asked us to implement features for copyright control, so they could sell their books to students ensure they couldn't exchange copies. In Paraguay, a local publisher came up with another scheme involving Adobe Flash to limit what users could do or not do with books. With the GPLv2 alone, any deployment or hardware vendor could make a deal with a publisher and turn Sugar into a Kindle full of DRM. So my questions are - What's the upside? I think the upsides are numerous. They're all given in the GPLv3 quick guide which I linked in my previous email. Further readings: http://www.gnu.org/licenses/gpl-faq.html http://www.gnu.org/licenses/rms-why-gplv3.html - At what point do we say hey, this has scant upside, and negative controversy around it, let's spend our time in productive things instead? Which negative controversy, the one you're personally fueling? This is kind of a circular argument :-) In fact, this argument could also be reversed: hey, instead of fighting the GPLv3, why don't we spend our time doing productive things instead? Seriously: calling something a waste of time is just an old trick that can be used to shoot down any proposal: if the license upgrade were really so unimportant, you wouldn't take the time to argue against it. You've expressed some valid concerns and I believe I've responded satisfactorily to all of them. If not, I'm glad to hear a counter-argument from you. -- 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
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
Hi Bernie, On Fri, Apr 22 2011, Bernie Innocenti wrote: You've expressed some valid concerns and I believe I've responded satisfactorily to all of them. If not, I'm glad to hear a counter-argument from you. I think you've repeatedly ignored Scott's claim that you can't modify COPYING or the source files because that would be *changing* the license, rather than taking advantage of GPLv3 redistribution rights. Can you ask Brett or someone at the FSF what the right thing to do is? - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
Hi, On Fri, Apr 22 2011, Chris Ball wrote: I think you've repeatedly ignored Scott's claim that you can't modify COPYING or the source files because that would be *changing* the license, rather than taking advantage of GPLv3 redistribution rights. Can you ask Brett or someone at the FSF what the right thing to do is? I chatted with some FSF staffers on IRC, they agree with Bernie's interpretation that modifying COPYING and the source headers *is* the way that you choose to redistribute under the GPLv3+ instead, and that it's a modification of the license that was explicitly allowed ahead of time by the or later clause. They haven't yet been able to find any documentation that explains this or backs it up, though. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
chris wrote: Hi, On Fri, Apr 22 2011, Chris Ball wrote: I think you've repeatedly ignored Scott's claim that you can't modify COPYING or the source files because that would be *changing* the license, rather than taking advantage of GPLv3 redistribution rights. Can you ask Brett or someone at the FSF what the right thing to do is? I chatted with some FSF staffers on IRC, they agree with Bernie's interpretation that modifying COPYING and the source headers *is* the way that you choose to redistribute under the GPLv3+ instead, and that it's a modification of the license that was explicitly allowed ahead of time by the or later clause. They haven't yet been able to find any documentation that explains this or backs it up, though. i think i've missed the point of all this. bernie's original mail points to the FSF rationale for GPL3 as the reason for moving sugar to GPL3, but somehow i think there must be more to it. i.e., what exactly are the arguments in favor of _sugar_ changing licenses? i have no stake in this decision at all -- i'm just wondering about the why. paul =- paul fox, p...@laptop.org ___ 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
