Re: [Sugar-devel] [IAEP] ANNOUNCE: Moving Sugar to GPLv3+
technical discussion snipped Since this is the core point of disagreement within the community, the act of accepting or rejecting the GPLv3 assumes for us the deeper meaning of refusing or endorsing TiVo-ization and DRM in conjunction with Sugar. 'Premature optimization is the root of all evil' -- Donald Knuth The question is: Of the tasks Sugar Labs can do to improve the educational valued of Sugar and collaboration within the ecosystem is tweaking the license among the critical tasks? david ___ 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 Mon, 2011-04-25 at 02:00 -0400, David Farning wrote: 'Premature optimization is the root of all evil' -- Donald Knuth The question is: Of the tasks Sugar Labs can do to improve the educational valued of Sugar and collaboration within the ecosystem is tweaking the license among the critical tasks? What are the critical tasks we should be working on and why couldn't we work on them in parallel with the license update? The argument that updating the license would cost us too much time has already been made... three times. If we'd stop making the same argument over and over, we'd save *plenty* of time! :-) -- 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 Mon, Apr 25, 2011 at 7:14 AM, Bernie Innocenti ber...@sugarlabs.orgwrote: [cc += christoph] On Fri, 2011-04-22 at 21:25 -0400, Paul Fox wrote: 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. Sorry Paul, I had missed your reply to the list. You and Christoph asked similar questions and I'd like to answer both of them comprehensively, but tonight I'm too tired to write more than just a short summary :-) To me, the reasons already given in the GPLv3 quick guide (*) are relevant to most free software, and therefore also to Sugar. Even if some of the reasons for updating the license are of legal nature and we're not lawyers, it doesn't mean there's no tangible advantage for the project. A license is a legal document, after all, so if we're looking for technical advantages, we're simply looking in the wrong place. Christoph also asked what strategic advantages the GPLv3 would bring in the surrounding ecosystem: Sugar is a member project of the Software Freedom Conservancy, and has a strong bound with the Free Software Foundation in the form of donated hosting and infrastructure for the past 3 years. In this regard, it makes sense for us to be using the latest published version of their license. If we managed to make Sugar endorsed by the GNU project, or even make it to the high-priority free software list, this could result in extra visibility and funding for development. Currently, Sugar official releases don't even make it to the LWN announcements page, unlike tiny and obscure GNU packages such as m4 and gettext. The main point being debated in this thread is the so-called anti-TiVo clause. For people like me, it's a necessary fix to make the GPL continue to work as intended in this era of locked-down devices and laws prohibiting modifications such as the DMCA. For Martin (and Scott?) the anti-TiVo clause is overly restrictive and the manifestation of a radical political agenda. Since this is the core point of disagreement within the community, the act of accepting or rejecting the GPLv3 assumes for us the deeper meaning of refusing or endorsing TiVo-ization and DRM in conjunction with Sugar. (*) http://www.gnu.org/licenses/quick-guide-gplv3.html Bernie, thanks a lot for your response, much appreciated. Having said that I'd be lying if I claimed to understand all the details now. Both sides of the argument seem to make some good points though without having any experience in the area nor training in the deeper legal issues I personally think it's hard if not impossible to make a call here. So what I'm more focused on at this point is the process for this decision. You started this thread by writing The oversight board is considering a motion to upgrade the license of Sugar from GPLv2 or later to GPLv3 or later. which sounds like SLOBs will be taking an executive decision on this matter, or am I misunderstanding something here? If that is indeed the case then I'd love to hear what other board members think because apart from you and Sebastian nobody has commented on this topic yet. Secondly you wrote 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. It can be argued that contributors and maintainers have so far spoken up in this thread but users and distributors haven't. I'm not quite sure why this is the case but it's probably safe to assume that David has somewhat of a point when he says that licensing isn't necessarily on the critical path of tasks for users and deployments (which says nothing about whether licensing should or shouldn't be a critical task for Sugar Labs itself IMHO). Additionally I would suggest that reaching out to the relevant people and organisations privately, pointing them to this thread, and encouraging them to post their opinion might get some replies as not everybody follows sugar-devel and IAEP religiously. Cheers, 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+
On 11-04-25 at 02:14pm, Christoph Derndorfer wrote: Secondly you wrote 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. It can be argued that contributors and maintainers have so far spoken up in this thread but users and distributors haven't. I'm not quite sure why this is the case but it's probably safe to assume that David has somewhat of a point when he says that licensing isn't necessarily on the critical path of tasks for users and deployments (which says nothing about whether licensing should or shouldn't be a critical task for Sugar Labs itself IMHO). Additionally I would suggest that reaching out to the relevant people and organisations privately, pointing them to this thread, and encouraging them to post their opinion might get some replies as not everybody follows sugar-devel and IAEP religiously. Well, let me then speak up as package maintainer for Debian: I wholeheartedly agree with Martin here. GPL-2+ signals a different political message than GPL-3+. I am quite interested myself in the more aggressive GPL-3, but find it problematic FSF decided to label GPL-3 as a successor of GPL-2 instead of renaming the stem. The reason is that in my opinion GPL-3 - as Aferro-GPL - is not improved wording of same intended license, but changes the game. I therefore find it rude of projects to abuse the flaw in FSF license naming by bumping from GPL2 to GPL3. It is cheating the authors. I lack some responses in this thread from authors with the viewpoint of oh thank you for taking care of my interests and refining my original intend by bumping to that new version of the GPL which more clearly states the same thing as I wanted back when I released my code to you. That was representing myself only. Debian officially is not pushing towards GPLv3 but accepts anything that fits the Debian Free Software Guidelines - which includes both agressive licenses like GPLv2 and GPLv3, and passive ones like BSD-3-clause and Expat (a.k.a. MIT). I have very much enjoyed following this discussion. Thanks for the well reflected arguments on both sides! Regards, and good luck with this process, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] License notices in GPLvN-or-later software
Hi everyone, In the discussion about the proposal to move Sugar to GPLv3+, there's been some disagreement about what can and can't be done with the project's license notices and the like. Questions about this are getting bounced up to me through different channels -- so much that cjb asked if I could answer questions here directly. So here I am. :) I think a big reason this conversation has been difficult is because a lot of the terms, like relicensing, are not well-defined. Usually the context makes their real meaning clear enough, but since we're talking about future plans here, I suspect that people mean different things by it. So I'm going to try to step away from that kind of language and work through the mechanics of what is or isn't required, and why. I'll start by talking about the licensing of the software on a sort of abstract level, and then move on to what that means for license notices specifically. ### Licensing programs with multiple licenses In the free software world, it rarely makes sense to talk about changing the license for a program. Here I'm talking about releasing unchanged software under a new license, not a project's decision to release future versions under a new license. When this happens, it's almost always the case that what's really happening is that the software is now available under another license in addition to all the license(s) it was available under previously. None of the old licenses are revoked, the software may still see wide distribution under one or more of those old licenses, and often they're still readily available from the original VCS repository. So when we say things like You can't change the license on the software, it would be more accurate to say something like You can't distribute the software under a particular license unless its copyright holders give you permission. The distinction here is important when software is released under multiple licenses. Normally when we think of software released under multiple licenses, we think of dual-licensed software like Perl or Mozilla's tri-license. When software is distributed this way, you may distribute it further under the terms of any single one of the licenses, or some combination of them. This is the principle that lets projects get GPL compatibility by dual-licensing under a GPL-compatible license. If you had to respect *all* the licenses when you distributed such software, this common licensing strategy wouldn't work. It only works because developers who need GPL compatibility, because they're combining the work with GPL-covered code, are able to follow the terms of the compatible license, and only that compatible license. And that's fine, because the copyright holders gave them permission to distribute the work under that license -- as well as permission to distribute it under another, GPL-incompatible license. Software released under some version of the GPL or (at your option) any later version works on exactly the same principles (at least, once a later version of the GPL becomes available). Right now, software that's GPLv2-or-later is, practically speaking, dual-licensed: you can distribute it under the terms of GPLv2 and/or GPLv3. People who say that You can't change the license of a GPLv2-or-later program to GPLv3-or-later have a good general principle in mind, but are misapplying it. It would translate to You can't distribute a GPLv2-or-later program under GPLv3-or-later without the copyright holders' permission. But that statement doesn't mean much. The copyright holders already gave recipients permission to distribute the program under GPLv3-or-later: that's the whole point of the -or-later language. So there's no problem if a party receives code under GPLv2-or-later, and distributes it under GPLv3-or-later. Now let's look at what happens with the license notices if they do that. ### Notices on works under multiple licenses Maintaining copyright notices on a work -- the lines like Copyright 2011 John Doe -- is required by copyright law. Maintaining license notices is a condition of almost every free software license. (Off the top of my head, the only exception I can recall is the WTFPL -- 'nuff said.) In GPLv3, this condition is in section 4; it says that when you convey the work, you must keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code. If a party distributes a work under GPLv3-or-later, they are only required to include license notices that refer to GPLv3-or-later. A party who converts GPLv2-or-later notices on a work to GPLv3-or-later notices is in compliance with this condition, as long as they follow all the other conditions in GPLv3 when they distribute the work. And one of those conditions is that they *must* include a copy of the text of GPLv3. Please don't read this condition too strictly, though. It's acceptable to distribute a work under GPLv3 with GPLv2-or-later
Re: [Sugar-devel] [PATCH] Start implementation de new toolbars
A little off topic, do you know if the network.py file is used in Record right now? Gonzalo On Tue, Apr 19, 2011 at 2:47 PM, Daniel Drake d...@laptop.org wrote: On 15 April 2011 15:06, Gonzalo Odiard godi...@sugarlabs.org wrote: I have not moved the record buttons yet. The general design of the UI is discussed in http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar#Ideas_to_discuss_the_UI_for_Record Thanks for working on this. I had a look at the results. It is hard to see which mode you are in, e.g. if you click on video then on the scissors, it's not obvious if you are in video or audio or photo mode. Also, if you are recording a video and click on the photo icon, the mode change isn't registered: 1. switch to video icon 2. start recording video 3. switch to camera icon 4. stop recording video 5. click shutter again - it starts recording a video, even though you are in photo mode As for the code, it looks fine so far except for code that gets commented out and EditToolbar's copy member doesn't need to be a class variable. Thanks, Daniel -- Gonzalo Odiard SugarLabs Argentina ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Start implementation de new toolbars
On 25 April 2011 20:21, Gonzalo Odiard godi...@sugarlabs.org wrote: A little off topic, do you know if the network.py file is used in Record right now? thanks, not sure how that got there. Removed. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Start implementation de new toolbars
Good :) On Mon, Apr 25, 2011 at 4:32 PM, Daniel Drake d...@laptop.org wrote: On 25 April 2011 20:21, Gonzalo Odiard godi...@sugarlabs.org wrote: A little off topic, do you know if the network.py file is used in Record right now? thanks, not sure how that got there. Removed. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs Argentina ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] NetworkManager 0.8 --- 0.9
On Wed, Apr 13, 2011 at 4:38 PM, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Apr 11, 2011 at 3:37 PM, Simon Schampijer si...@schampijer.de wrote: Hi, NetworkManager broke API compatibility with the latest version 0.9 [1][2]. This means we have to switch to the new API sooner or later. F15, which includes NM 0.9, does hit that issue already - hence you can not connect to an AP anymore. This is an item that should go into 0.94 and F15 might carry a patch (if we get one - help welcome). Not sure if its of any assistance but here's the patch anaconda used for their update to NM-0.9 if any one has some time to hack up a patch for me to test. http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=2fc520c7bb745e1dacfab547faa9f09e060ceaa7 I've read up on this and poked it some more today, I'm only just learning python so its a bit over my head. That said it doesn't look too hard or time consuming for someone who knows the codebase better than I. It breaks down AFAICT to the following changes: - Changes for check online for Activities. This should be simple and only a minor change - Change for connecting to a Wireless AP. Major change for this is to move from user settings to system settings and the links below seem to make it look simple. I've not checked GSM, ad-hoc wifi or mesh (not supported in SoaS). Peter http://mail.gnome.org/archives/networkmanager-list/2011-March/msg00098.html http://projects.gnome.org/NetworkManager/developers/migrating-to-09/ref-migrating.html https://live.gnome.org/NetworkManager/ApiSimplify ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
