Re: [Sugar-devel] [Systems] Moving pootle to github
Hi, not sure what Simon and Manuel think about this, but unless someone help us out with this asap, I think we should go ahead, resync git.sugarlabs.org - github.com, and rename the git.sugarlabs.org repos to obsolete-*. I really don't want to keep two repos with diverged history around longer, we need to fix that even if temporarily breaks pootle. On 2 June 2013 21:33, Bernie Innocenti ber...@codewiz.org wrote: +rralcala,alsroot Roberto, this might be a good task to get you started on Pootle. Chris and Aleksey can probably assist you. On 06/02/2013 10:09 AM, Daniel Narvaez wrote: Ping? On 23 May 2013 17:32, Daniel Narvaez dwnarv...@gmail.com mailto:dwnarv...@gmail.com wrote: Hello, we need to move pootle to push on github for a few modules (see https://github.com/sugarlabs/). We will also need to turn it off for a bit while we resync the repositories. Who has access/knowledge to help with this? -- Daniel Narvaez -- Daniel Narvaez ___ Systems mailing list syst...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/systems -- _ // Bernie Innocenti \X/ http://codewiz.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] Moving pootle to github
2013/6/7 Daniel Narvaez dwnarv...@gmail.com: Hi, not sure what Simon and Manuel think about this, but unless someone help us out with this asap, I think we should go ahead, resync git.sugarlabs.org - github.com, and rename the git.sugarlabs.org repos to obsolete-*. I really don't want to keep two repos with diverged history around longer, we need to fix that even if temporarily breaks pootle. +1 -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] Moving pootle to github
On Fri, Jun 07, 2013 at 02:55:09PM +0200, Daniel Narvaez wrote: Hi, not sure what Simon and Manuel think about this, but unless someone help us out with this asap, I think we should go ahead, resync git.sugarlabs.org - github.com, and rename the git.sugarlabs.org repos to obsolete-*. I really don't want to keep two repos with diverged history around longer, we need to fix that even if temporarily breaks pootle. You mean moving glucose/fructose repos? Because these are only a few of git.sl.o repos. Aslo, deprecating git.slo becuase of moving these few repos to github sounds really unrelated. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] Moving pootle to github
On 7 June 2013 15:07, Aleksey Lim alsr...@sugarlabs.org wrote: On Fri, Jun 07, 2013 at 02:55:09PM +0200, Daniel Narvaez wrote: Hi, not sure what Simon and Manuel think about this, but unless someone help us out with this asap, I think we should go ahead, resync git.sugarlabs.org- github.com, and rename the git.sugarlabs.org repos to obsolete-*. I really don't want to keep two repos with diverged history around longer, we need to fix that even if temporarily breaks pootle. You mean moving glucose/fructose repos? No, just glucose. You can see the exact list of modules on https://github.com/sugarlabs/ Because these are only a few of git.sl.o repos. Yup, never said we are moving all of them. Aslo, deprecating git.slo becuase of moving these few repos to github sounds really unrelated. I suppose I've been unclear. I'm just talking about renaming the sugar repository we moved on github, not git.slo as a whole ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] Moving pootle to github
On Fri, Jun 07, 2013 at 03:10:13PM +0200, Daniel Narvaez wrote: On 7 June 2013 15:07, Aleksey Lim alsr...@sugarlabs.org wrote: On Fri, Jun 07, 2013 at 02:55:09PM +0200, Daniel Narvaez wrote: Hi, not sure what Simon and Manuel think about this, but unless someone help us out with this asap, I think we should go ahead, resync git.sugarlabs.org- github.com, and rename the git.sugarlabs.org repos to obsolete-*. I really don't want to keep two repos with diverged history around longer, we need to fix that even if temporarily breaks pootle. You mean moving glucose/fructose repos? No, just glucose. You can see the exact list of modules on https://github.com/sugarlabs/ Because these are only a few of git.sl.o repos. Yup, never said we are moving all of them. Aslo, deprecating git.slo becuase of moving these few repos to github sounds really unrelated. I suppose I've been unclear. I'm just talking about renaming the sugar repository we moved on github, not git.slo as a whole ok -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar on Android
Hello devs, In the past weeks I've been looking at how an Android Sugar shell could provide the same services as GTK Sugar shell to the web activities. The research is now documented in two pages at developer.sugarlabs.org: - Architecture http://developer.sugarlabs.org/web-architecture.md.html - Android implementation details http://developer.sugarlabs.org/android.md.html As the last page say, the service lives temporarily inside a color chooser app: repo: https://github.com/manuq/aboutmejs-android/ apk: https://github.com/manuq/aboutmejs-android/blob/master/bin/AboutMe.apk And it contains just one setting: the user colors. You can try it together with this other app: repo: https://github.com/manuq/clockjs-android apk: https://github.com/manuq/clockjs-android/blob/master/bin/ClockJS.apk I would appreciate any feedback in the docs or in the implementation. Thanks. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Web UI
Hello, I want to report the slow but steady progress I'm doing on the web activities UI. I started a samples repository that servers as a showcase for activity developers and as a visual debugging tool for sugar-web developers. published at: https://github.com/sugarlabs/sugar-web-samples repo: https://github.com/sugarlabs/sugar-web-samples All is measured according to cell and subcell sizes as the original developers did. We have a grid for visual debugging: http://sugarlabs.github.io/sugar-web-samples/grid.html So come join me, it is a great opportunity to learn! The list of tasks is at: https://github.com/sugarlabs/roadmap/issues/8 A good entry point is: theme the radio buttons input type=radio.and checkboxes input type=checkbox.. You will only need CSS and the SVGs inside sugar-artwork. Cheers, -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] developer.sugarlabs.org index
Hey, I think for the introductory docs it would be much better to have index with titles rather then filenames. I don't think docker supports it but perhaps we could add it (just pick the first title in the document) and upstream it. It's probably a good time to think if we want other layout changes (separated index and links at the top a la flask.pooco.org?), so that we don't waste time on the sidebar if we want something different. Thoughts? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Web UI
Forgot to say that the whole point of measuring everything in subcell sizes is that it will allow us to support different screens densities and sizes, using the CSS media query. 2013/6/7 Manuel Quiñones ma...@laptop.org: Published at: http://sugarlabs.github.io/sugar-web-samples/ 2013/6/7 Manuel Quiñones ma...@laptop.org: Hello, I want to report the slow but steady progress I'm doing on the web activities UI. I started a samples repository that servers as a showcase for activity developers and as a visual debugging tool for sugar-web developers. published at: https://github.com/sugarlabs/sugar-web-samples repo: https://github.com/sugarlabs/sugar-web-samples All is measured according to cell and subcell sizes as the original developers did. We have a grid for visual debugging: http://sugarlabs.github.io/sugar-web-samples/grid.html So come join me, it is a great opportunity to learn! The list of tasks is at: https://github.com/sugarlabs/roadmap/issues/8 A good entry point is: theme the radio buttons input type=radio.and checkboxes input type=checkbox.. You will only need CSS and the SVGs inside sugar-artwork. Cheers, -- .. manuq .. -- .. manuq .. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] developer.sugarlabs.org index
An easy way to generate a custom index would be to generate sidebar-less pages with docker and put them inside an iframe, building links/index with handlebars templates, from an index.json. I'm not in love with the sidebar for introductory docs, I like the pooco approach more http://flask.pocoo.org/docs/foreword/#configuration-and-conventions On Friday, 7 June 2013, Daniel Narvaez wrote: Hey, I think for the introductory docs it would be much better to have index with titles rather then filenames. I don't think docker supports it but perhaps we could add it (just pick the first title in the document) and upstream it. It's probably a good time to think if we want other layout changes (separated index and links at the top a la flask.pooco.org?), so that we don't waste time on the sidebar if we want something different. Thoughts? -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] developer.sugarlabs.org index
Well perhaps that's too fancy... Going somewhat crazy with all these nice js libs. Might be enough to add the top links in the markdown (I think you can put plain html in it?). A bit more annoying to maintain but probably not much On Friday, 7 June 2013, Daniel Narvaez wrote: An easy way to generate a custom index would be to generate sidebar-less pages with docker and put them inside an iframe, building links/index with handlebars templates, from an index.json. I'm not in love with the sidebar for introductory docs, I like the pooco approach more http://flask.pocoo.org/docs/foreword/#configuration-and-conventions On Friday, 7 June 2013, Daniel Narvaez wrote: Hey, I think for the introductory docs it would be much better to have index with titles rather then filenames. I don't think docker supports it but perhaps we could add it (just pick the first title in the document) and upstream it. It's probably a good time to think if we want other layout changes (separated index and links at the top a la flask.pooco.org?), so that we don't waste time on the sidebar if we want something different. Thoughts? -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on Android (Manuel Qui?ones)
In the past weeks I've been looking at how an Android Sugar shell could provide the same services as GTK Sugar shell to the web activities. The research is now documented in two pages at developer.sugarlabs.org: - Architecture http://developer.sugarlabs.org/web-architecture.md.html - Android implementation details http://developer.sugarlabs.org/android.md.html Waooo, great stuff, nice ! Lionel. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on sugar-web in the apple store, at least including the lib locally. I suppose it would be fine if you loaded it from a server, but then you need security restrictions if you implement any kind of system integration. On Friday, 3 May 2013, Daniel Narvaez wrote: Hello, we need to decide how to license the new javascript libraries. I am mostly clueless about the topic and I'm honestly scared to start this thread, please be gentle :) Following is the rationale I came up with for Agora. I think it probably applies to the sugar-html libraries too. Feedback would be very welcome as we are no expert. --- I spent some time trying to decide which license is better for the various part of Agora. It's an hard and important decision, I'm not a lawyer and not even an expert but we need to make a call. My understanding is that a license is better than nothing. (L)GPLv2 * Copyleft. Requires all the modifications to be made freely available. * Incompatible with Apache. Pretty bad, a lot of code already licensed that way and growing fast (especially in the javascript world). (L)GPLv3 * Copyleft * Compatiible with Apache. * Anti-tivoization clause. Mixed bag, would it prevent us to run on hardware we are interested in? One problematic case I can think of is distributing an activity through the Apple store. We wouldn't be able to do that. Though people could still install the activity as a web app, from the browser. Maybe that's good enough? * Latest version. Better wording etc. Patents protection. * We can distribute the sugar icons under LGPLv3, without requiring any relicensing, because of the or later clause. * My understanding is that if xi-* is LGPL, proprietary applications could still use it without making modifications. The situation is not as clear as for the traditional linked libraries case but from http://www.gnu.org/licenses/lgpl-java.html I'd think we are fine. Apache * Non copyleft. It would be more friendly to companies that might want to reuse code in their products. But is that likely to happen? Both xi and omega are pretty agora specific. Still I think it's a good license to use for more generic bits that we might develop (I used it for some python helpers I'm using in eta for example). * It seems to be the best permissive license because of the patents protection. It's the most popular at least. So I think there two choices basically: 1 Copyleft VS non copyleft. I think copyleft has advantages and practically no real disadvantages for eta, xi and omega. 2 GPLv2 VS GPLv3. Compatibility with Apache would be good (maybe not essential though? We could still use apache libraries I would think, just not freely cut/paste code). Anti-tivoization is tricky, I honestly can't make strong points one way or another. While I was initially sympathetic with the claims that v3 is political I think http://tieguy.org/blog/2007/06/28/gpl-v3-the-qa-part-4-odds-and-ends/ is a good rebuttal of that argument. I'm somewhat worried about not being able to distribute on some devices but, especially since we can always run remotely, I'm not convinced we should opt out of v3 because of that., -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. On Saturday, 8 June 2013, Daniel Narvaez wrote: We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on sugar-web in the apple store, at least including the lib locally. I suppose it would be fine if you loaded it from a server, but then you need security restrictions if you implement any kind of system integration. On Friday, 3 May 2013, Daniel Narvaez wrote: Hello, we need to decide how to license the new javascript libraries. I am mostly clueless about the topic and I'm honestly scared to start this thread, please be gentle :) Following is the rationale I came up with for Agora. I think it probably applies to the sugar-html libraries too. Feedback would be very welcome as we are no expert. --- I spent some time trying to decide which license is better for the various part of Agora. It's an hard and important decision, I'm not a lawyer and not even an expert but we need to make a call. My understanding is that a license is better than nothing. (L)GPLv2 * Copyleft. Requires all the modifications to be made freely available. * Incompatible with Apache. Pretty bad, a lot of code already licensed that way and growing fast (especially in the javascript world). (L)GPLv3 * Copyleft * Compatiible with Apache. * Anti-tivoization clause. Mixed bag, would it prevent us to run on hardware we are interested in? One problematic case I can think of is distributing an activity through the Apple store. We wouldn't be able to do that. Though people could still install the activity as a web app, from the browser. Maybe that's good enough? * Latest version. Better wording etc. Patents protection. * We can distribute the sugar icons under LGPLv3, without requiring any relicensing, because of the or later clause. * My understanding is that if xi-* is LGPL, proprietary applications could still use it without making modifications. The situation is not as clear as for the traditional linked libraries case but from http://www.gnu.org/licenses/lgpl-java.html I'd think we are fine. Apache * Non copyleft. It would be more friendly to companies that might want to reuse code in their products. But is that likely to happen? Both xi and omega are pretty agora specific. Still I think it's a good license to use for more generic bits that we might develop (I used it for some python helpers I'm using in eta for example). * It seems to be the best permissive license because of the patents protection. It's the most popular at least. So I think there two choices basically: 1 Copyleft VS non copyleft. I think copyleft has advantages and practically no real disadvantages for eta, xi and omega. 2 GPLv2 VS GPLv3. Compatibility with Apache would be good (maybe not essential though? We could still use apache libraries I would think, just not freely cut/paste code). Anti-tivoization is tricky, I honestly can't make strong points one way or another. While I was initially sympathetic with the claims that v3 is political I think http://tieguy.org/blog/2007/06/28/gpl-v3-the-qa-part-4-odds-and-ends/ is a good rebuttal of that argument. I'm somewhat worried about not being able to distribute on some devices but, especially since we can always run remotely, I'm not convinced we should opt out of v3 because of that., -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
Ugh one issue with Apache is that I think we would need to get permission to relicense the svg icons under apache from all the people that contributed to them. Do you think that will be possible? People that contributed but doesn't seem to be involved with the project anymore. Eben Eliason Marco Pesenti Gritti Tomeu Vizoso Still around Scott Ananian benzea erikos Martin Abente Walter Bender godiard Manuel Quinones From the git log of the icons dir. On Saturday, 8 June 2013, Daniel Narvaez wrote: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. On Saturday, 8 June 2013, Daniel Narvaez wrote: We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on sugar-web in the apple store, at least including the lib locally. I suppose it would be fine if you loaded it from a server, but then you need security restrictions if you implement any kind of system integration. On Friday, 3 May 2013, Daniel Narvaez wrote: Hello, we need to decide how to license the new javascript libraries. I am mostly clueless about the topic and I'm honestly scared to start this thread, please be gentle :) Following is the rationale I came up with for Agora. I think it probably applies to the sugar-html libraries too. Feedback would be very welcome as we are no expert. --- I spent some time trying to decide which license is better for the various part of Agora. It's an hard and important decision, I'm not a lawyer and not even an expert but we need to make a call. My understanding is that a license is better than nothing. (L)GPLv2 * Copyleft. Requires all the modifications to be made freely available. * Incompatible with Apache. Pretty bad, a lot of code already licensed that way and growing fast (especially in the javascript world). (L)GPLv3 * Copyleft * Compatiible with Apache. * Anti-tivoization clause. Mixed bag, would it prevent us to run on hardware we are interested in? One problematic case I can think of is distributing an activity through the Apple store. We wouldn't be able to do that. Though people could still install the activity as a web app, from the browser. Maybe that's good enough? * Latest version. Better wording etc. Patents protection. * We can distribute the sugar icons under LGPLv3, without requiring any relicensing, because of the or later clause. * My understanding is that if xi-* is LGPL, proprietary applications could still use it without making modifications. The situation is not as clear as for the traditional linked libraries case but from http://www.gnu.org/licenses/lgpl-java.html I'd think we are fine. Apache * Non copyleft. It would be more friendly to companies that might want to reuse code in their products. But is that likely to happen? Both xi and omega are pretty agora specific. Still I think it's a good license to use for more generic bits that we might develop (I used it for some python helpers I'm using in eta for example). * It seems to be the best permissive license because of the patents protection. It's the most popular at least. So I think there two choices basically: 1 Copyleft VS non copyleft. I think copyleft has advantages and practically no real disadvantages for eta, xi and omega. 2 GPLv2 VS GPLv3. Compatibility with Apache would be good (maybe not essential though? We could still use apache libraries I would think, just not freely cut/paste code). Anti-tivoization is tricky, I honestly can't make strong points one way or another. While I was initially sympathetic with the claims that v3 is political I think http://tieguy.org/blog/2007/06/28/gpl-v3-the-qa-part-4-odds-and-ends/is a good rebuttal of that argument. I'm somewhat worried about not being able to distribute on some devices but, especially since we can always run remotely, I'm not convinced we should opt out of v3 because of that., -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
Well permission to double license really. On Saturday, 8 June 2013, Daniel Narvaez wrote: Ugh one issue with Apache is that I think we would need to get permission to relicense the svg icons under apache from all the people that contributed to them. Do you think that will be possible? People that contributed but doesn't seem to be involved with the project anymore. Eben Eliason Marco Pesenti Gritti Tomeu Vizoso Still around Scott Ananian benzea erikos Martin Abente Walter Bender godiard Manuel Quinones From the git log of the icons dir. On Saturday, 8 June 2013, Daniel Narvaez wrote: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. On Saturday, 8 June 2013, Daniel Narvaez wrote: We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on sugar-web in the apple store, at least including the lib locally. I suppose it would be fine if you loaded it from a server, but then you need security restrictions if you implement any kind of system integration. On Friday, 3 May 2013, Daniel Narvaez wrote: Hello, we need to decide how to license the new javascript libraries. I am mostly clueless about the topic and I'm honestly scared to start this thread, please be gentle :) Following is the rationale I came up with for Agora. I think it probably applies to the sugar-html libraries too. Feedback would be very welcome as we are no expert. --- I spent some time trying to decide which license is better for the various part of Agora. It's an hard and important decision, I'm not a lawyer and not even an expert but we need to make a call. My understanding is that a license is better than nothing. (L)GPLv2 * Copyleft. Requires all the modifications to be made freely available. * Incompatible with Apache. Pretty bad, a lot of code already licensed that way and growing fast (especially in the javascript world). (L)GPLv3 * Copyleft * Compatiible with Apache. * Anti-tivoization clause. Mixed bag, would it prevent us to run on hardware we are interested in? One problematic case I can think of is distributing an activity through the Apple store. We wouldn't be able to do that. Though people could still install the activity as a web app, from the browser. Maybe that's good enough? * Latest version. Better wording etc. Patents protection. * We can distribute the sugar icons under LGPLv3, without requiring any relicensing, because of the or later clause. * My understanding is that if xi-* is LGPL, proprietary applications could still use it without making modifications. The situation is not as clear as for the traditional linked libraries case but from http://www.gnu.org/licenses/lgpl-java.html I'd think we are fine. Apache * Non copyleft. It would be more friendly to companies that might want to reuse code in their products. But is that likely to happen? Both xi and omega are pretty agora specific. Still I think it's a good license to use for more generic bits that we might develop (I used it for some python helpers I'm using in eta for example). * It seems to be the best permissive license because of the patents protection. It's the most popular at least. So I think there two choices basically: 1 Copyleft VS non copyleft. I think copyleft has advantages and practically no real disadvantages for eta, xi and omega. 2 GPLv2 VS GPLv3. Compatibility with Apache would be good (maybe not essential though? We could still use apache libraries I would think, just not freely cut/paste code). Anti-tivoization is tricky, I honestly can't make strong points one way or another. While I was initially sympathetic with the claims that v3 is political I think http://tieguy.org/blog/2007/06/28/gpl-v3-the-qa-part-4-odds-and-ends/is a good rebuttal of that argument. I'm somewhat worried about not being able to distribute on some devices but, especially since we can always run remotely, I'm not convinced we should opt out of v3 because of that., -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
We already had this discussion two years ago, is the situation with the javascript activities different to need start this discussion again? Gonzalo On 06/14/2011 05:42 PM, Luke Faraone wrote: This is a vote to determine the suggested license for future releases of Sugar. This poll will run from right now until Wed Jun 29 2011 at midnight UTC-4. Sorry for the late update; the reporting mechanism for our voting software temporarily broke. Summary: the winner was **GNU GPL version 3, or any later version**. ## Results Details ## 55 out of 217 eligible members voted, or a little more than ¼. The full results of this election ranked the candidates in order of preference (from most preferred to least preferred): 1. GNU GPL version 3, or any later version 2. GNU GPL version 2, or any later version 3. Don't know or don't care Each number in the table below shows how many times the candidate on the left beat the matching candidate on the top. The winner is on the top of the left column. v3 v2 DC v3 -- 34 37 v2 21 -- 42 DC 18 13 -- 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. Full details (and alternative election method calculations) are visible at the Selectricity page linked in the original voting ticket email. Thanks, Luke FaraoneSugar Labs, Systems â: l...@sugarlabs.org I: lfaraone on irc.freenode.net On Fri, Jun 7, 2013 at 8:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Well permission to double license really. On Saturday, 8 June 2013, Daniel Narvaez wrote: Ugh one issue with Apache is that I think we would need to get permission to relicense the svg icons under apache from all the people that contributed to them. Do you think that will be possible? People that contributed but doesn't seem to be involved with the project anymore. Eben Eliason Marco Pesenti Gritti Tomeu Vizoso Still around Scott Ananian benzea erikos Martin Abente Walter Bender godiard Manuel Quinones From the git log of the icons dir. On Saturday, 8 June 2013, Daniel Narvaez wrote: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. On Saturday, 8 June 2013, Daniel Narvaez wrote: We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on sugar-web in the apple store, at least including the lib locally. I suppose it would be fine if you loaded it from a server, but then you need security restrictions if you implement any kind of system integration. On Friday, 3 May 2013, Daniel Narvaez wrote: Hello, we need to decide how to license the new javascript libraries. I am mostly clueless about the topic and I'm honestly scared to start this thread, please be gentle :) Following is the rationale I came up with for Agora. I think it probably applies to the sugar-html libraries too. Feedback would be very welcome as we are no expert. --- I spent some time trying to decide which license is better for the various part of Agora. It's an hard and important decision, I'm not a lawyer and not even an expert but we need to make a call. My understanding is that a license is better than nothing. (L)GPLv2 * Copyleft. Requires all the modifications to be made freely available. * Incompatible with Apache. Pretty bad, a lot of code already licensed that way and growing fast (especially in the javascript world). (L)GPLv3 * Copyleft * Compatiible with Apache. * Anti-tivoization clause. Mixed bag, would it prevent us to run on hardware we are interested in? One problematic case I can think of is distributing an activity through the Apple store. We wouldn't be able to do that. Though people could still install the activity as a web app, from the browser. Maybe that's good enough? * Latest version. Better wording etc. Patents protection. * We can distribute the sugar icons under LGPLv3, without requiring any relicensing, because of the or later clause. * My understanding is that if xi-* is LGPL, proprietary applications could still use it without making modifications. The situation is not as clear as for the traditional linked libraries case but from http://www.gnu.org/licenses/lgpl-java.html I'd think we are fine. Apache * Non copyleft. It would be more friendly to companies that might want to reuse code in their products. But is that likely to happen? Both xi and omega are pretty agora specific. Still I think it's a good license
Re: [Sugar-devel] Licensing of the javascript libraries
Yes I think it's very different because using GPLv2 would mean we can't use
Apache licensed libraries, which are a big percentage of available js
libraries.
On Saturday, 8 June 2013, Gonzalo Odiard wrote:
We already had this discussion two years ago,
is the situation with the javascript activities different to need
start this discussion again?
Gonzalo
On 06/14/2011 05:42 PM, Luke Faraone wrote:
This is a vote to determine the suggested license for future releases
of Sugar. This poll will run from right now until Wed Jun 29 2011 at
midnight UTC-4.
Sorry for the late update; the reporting mechanism for our voting
software temporarily broke.
Summary: the winner was **GNU GPL version 3, or any later version**.
## Results Details ##
55 out of 217 eligible members voted, or a little more than ¼.
The full results of this election ranked the candidates in order of
preference (from most preferred to least preferred):
1. GNU GPL version 3, or any later version
2. GNU GPL version 2, or any later version
3. Don't know or don't care
Each number in the table below shows how many times the candidate on the
left beat the matching candidate on the top. The winner is on the top of
the left column.
v3 v2 DC
v3-- 34 37
v221 -- 42
DC18 13 --
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.
Full details (and alternative election method calculations) are visible
at the Selectricity page linked in the original voting ticket email.
Thanks,
Luke FaraoneSugar Labs, Systems
✉: l...@sugarlabs.org javascript:_e({}, 'cvml', 'l...@sugarlabs.org');
I: lfaraone on irc.freenode.net
On Fri, Jun 7, 2013 at 8:59 PM, Daniel Narvaez
dwnarv...@gmail.comjavascript:_e({}, 'cvml', 'dwnarv...@gmail.com');
wrote:
Well permission to double license really.
On Saturday, 8 June 2013, Daniel Narvaez wrote:
Ugh one issue with Apache is that I think we would need to get permission
to relicense the svg icons under apache from all the people that
contributed to them. Do you think that will be possible?
People that contributed but doesn't seem to be involved with the project
anymore.
Eben Eliason
Marco Pesenti Gritti
Tomeu Vizoso
Still around
Scott Ananian
benzea
erikos
Martin Abente
Walter Bender
godiard
Manuel Quinones
From the git log of the icons dir.
On Saturday, 8 June 2013, Daniel Narvaez wrote:
I'm still undecided really but since it's important to make a call soon,
my vote goes for Apache, both for sugar-web and for activities we develop.
On Saturday, 8 June 2013, Daniel Narvaez wrote:
We really need to make a call here, we start to have a sizeable amount of
code and the first release is near. I tend to think gplv2 is not an option
because of the apache incompatibility. I would go for Apache if we want to
avoid issues with anti-tivoization, otherwise gplv3.
To point out a concrete problem we could have with gpl3... My
understanding is that you could not ship an activity based on sugar-web in
the apple store, at least including the lib locally. I suppose it would be
fine if you loaded it from a server, but then you need security
restrictions if you implement any kind of system integration.
On Friday, 3 May 2013, Daniel Narvaez wrote:
Hello,
we need to decide how to license the new javascript libraries. I am
mostly clueless about the topic and I'm honestly scared to start this
thread, please be gentle :)
Following is the rationale I came up with for Agora. I think it probably
applies to the sugar-html libraries too. Feedback would be very welcome as
we are no expert.
---
I spent some time trying to decide which license is better for the
various part of Agora. It's an hard and important decision, I'm not a
lawyer and not even an expert but we need to make a call. My understanding
is that a license is better than nothing.
(L)GPLv2
* Copyleft. Requires all the modifications to be made freely available.
* Incompatible with Apache. Pretty bad, a lot of code already licensed
that way and growing fast (especially in the javascript world).
(L)GPLv3
* Copyleft
* Compatiible with Apache.
* Anti-tivoization clause. Mixed bag, would it prevent us to run on
hardware we are interested in? One problematic case I can think of is
distributing an activity through the Apple store. We wouldn't be able to do
that. Though people could still install the activity as a web app, from the
browser. Maybe that's good enough?
* Latest version. Better wording etc. Patents protection.
* We can distribute the sugar icons under LGPLv3, without requiring any
relicensing, because of the or later clause.
* My understanding is that if xi-* is LGPL, proprietary applications
could still use it without making modifications. The situation is not as
clear as for the
Re: [Sugar-devel] Licensing of the javascript libraries
I'm actually a bit confused about the result of the one year ago discussion. I thought we decided to stay with gplv2 but the poll winner seems to be gplv3? Anyway even on gplv3 I think the situation is pretty different if nothing else because one of major goals of the web activities work is to bring activities on devices where tivoization might be an issue. On Saturday, 8 June 2013, Daniel Narvaez wrote: Yes I think it's very different because using GPLv2 would mean we can't use Apache licensed libraries, which are a big percentage of available js libraries. On Saturday, 8 June 2013, Gonzalo Odiard wrote: We already had this discussion two years ago, is the situation with the javascript activities different to need start this discussion again? Gonzalo On 06/14/2011 05:42 PM, Luke Faraone wrote: This is a vote to determine the suggested license for future releases of Sugar. This poll will run from right now until Wed Jun 29 2011 at midnight UTC-4. Sorry for the late update; the reporting mechanism for our voting software temporarily broke. Summary: the winner was **GNU GPL version 3, or any later version**. ## Results Details ## 55 out of 217 eligible members voted, or a little more than ¼. The full results of this election ranked the candidates in order of preference (from most preferred to least preferred): 1. GNU GPL version 3, or any later version 2. GNU GPL version 2, or any later version 3. Don't know or don't care Each number in the table below shows how many times the candidate on the left beat the matching candidate on the top. The winner is on the top of the left column. v3 v2 DC v3 -- 34 37 v2 21 -- 42 DC 18 13 -- 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. Full details (and alternative election method calculations) are visible at the Selectricity page linked in the original voting ticket email. Thanks, Luke FaraoneSugar Labs, Systems ✉: l...@sugarlabs.org I: lfaraone on irc.freenode.net On Fri, Jun 7, 2013 at 8:59 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Well permission to double license really. On Saturday, 8 June 2013, Daniel Narvaez wrote: Ugh one issue with Apache is that I think we would need to get permission to relicense the svg icons under apache from all the people that contributed to them. Do you think that will be possible? People that contributed but doesn't seem to be involved with the project anymore. Eben Eliason Marco Pesenti Gritti Tomeu Vizoso Still around Scott Ananian benzea erikos Martin Abente Walter Bender godiard Manuel Quinones From the git log of the icons dir. On Saturday, 8 June 2013, Daniel Narvaez wrote: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. On Saturday, 8 June 2013, Daniel Narvaez wrote: We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on sugar-web in the apple store, at least including the lib locally. I suppose it would be fine if you loaded it from a server, but then you need security restrictions if you implement any kind of system integration. On Friday, 3 May 2013, Daniel Narvaez wrote: Hello, we need to decide how to license the new javascript libraries. I am mostly clueless about the topic and I'm honestly scared to start this thread, please be gentle :) Following is the rationale I came up with for Agora. I think it probably applies to the sugar-html libraries too. Feedback would be very welcome as we are no expert. --- I spent some time trying to decide which license is better for the various part of Agora. It's an hard and important decision, I'm not a lawyer and not even an expert but we need to make a call. My understanding is that a license is better than nothing. (L)GPLv2 * Copyleft. Requires all the modifications to be made freely available. * Incompatible with Apache. Pretty bad, a lot of code already licensed that way and growing fast (especially in the javascript world). (L)GPLv3 * Copyleft * Compatiible with Apache. * Anti-tivoization clause. Mixed bag, would it prevent us to run on hardware we are interested in? One problematic case I can think of is distributing an activity through the Apple store. We wouldn't be able to do that. Though people could still install the activity as a web app, from the browser. Maybe that's good enough? * Latest version. Better wording
Re: [Sugar-devel] Licensing of the javascript libraries
On Fri, Jun 7, 2013 at 7:58 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Ugh one issue with Apache is that I think we would need to get permission to relicense the svg icons under apache from all the people that contributed to them. Do you think that will be possible? I am happy to reach out to Marco, Tomeu and Eben. -walter People that contributed but doesn't seem to be involved with the project anymore. Eben Eliason Marco Pesenti Gritti Tomeu Vizoso Still around Scott Ananian benzea erikos Martin Abente Walter Bender godiard Manuel Quinones From the git log of the icons dir. On Saturday, 8 June 2013, Daniel Narvaez wrote: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. On Saturday, 8 June 2013, Daniel Narvaez wrote: We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on sugar-web in the apple store, at least including the lib locally. I suppose it would be fine if you loaded it from a server, but then you need security restrictions if you implement any kind of system integration. On Friday, 3 May 2013, Daniel Narvaez wrote: Hello, we need to decide how to license the new javascript libraries. I am mostly clueless about the topic and I'm honestly scared to start this thread, please be gentle :) Following is the rationale I came up with for Agora. I think it probably applies to the sugar-html libraries too. Feedback would be very welcome as we are no expert. --- I spent some time trying to decide which license is better for the various part of Agora. It's an hard and important decision, I'm not a lawyer and not even an expert but we need to make a call. My understanding is that a license is better than nothing. (L)GPLv2 * Copyleft. Requires all the modifications to be made freely available. * Incompatible with Apache. Pretty bad, a lot of code already licensed that way and growing fast (especially in the javascript world). (L)GPLv3 * Copyleft * Compatiible with Apache. * Anti-tivoization clause. Mixed bag, would it prevent us to run on hardware we are interested in? One problematic case I can think of is distributing an activity through the Apple store. We wouldn't be able to do that. Though people could still install the activity as a web app, from the browser. Maybe that's good enough? * Latest version. Better wording etc. Patents protection. * We can distribute the sugar icons under LGPLv3, without requiring any relicensing, because of the or later clause. * My understanding is that if xi-* is LGPL, proprietary applications could still use it without making modifications. The situation is not as clear as for the traditional linked libraries case but from http://www.gnu.org/licenses/lgpl-java.html I'd think we are fine. Apache * Non copyleft. It would be more friendly to companies that might want to reuse code in their products. But is that likely to happen? Both xi and omega are pretty agora specific. Still I think it's a good license to use for more generic bits that we might develop (I used it for some python helpers I'm using in eta for example). * It seems to be the best permissive license because of the patents protection. It's the most popular at least. So I think there two choices basically: 1 Copyleft VS non copyleft. I think copyleft has advantages and practically no real disadvantages for eta, xi and omega. 2 GPLv2 VS GPLv3. Compatibility with Apache would be good (maybe not essential though? We could still use apache libraries I would think, just not freely cut/paste code). Anti-tivoization is tricky, I honestly can't make strong points one way or another. While I was initially sympathetic with the claims that v3 is political I think http://tieguy.org/blog/2007/06/28/gpl-v3-the-qa-part-4-odds-and-ends/ is a good rebuttal of that argument. I'm somewhat worried about not being able to distribute on some devices but, especially since we can always run remotely, I'm not convinced we should opt out of v3 because of that., -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
Hi, The poll winner was GPLv3 but the poll was non-binding, i.e. the community can't force contributors to switch licenses and nobody sent a patch to change license notices. I and other members of the community think it's important to support freedom by using copyleft, therefore most of our contributions are using GPLv3. I checked and it turns out Apache 2.0 license is compatible with GPLv3 (but incompatible with GPLv2): http://www.gnu.org/licenses/license-list.html#apache2 Regards, Sebastian El 07/06/13 19:38, Daniel Narvaez escribió: I'm actually a bit confused about the result of the one year ago discussion. I thought we decided to stay with gplv2 but the poll winner seems to be gplv3? Anyway even on gplv3 I think the situation is pretty different if nothing else because one of major goals of the web activities work is to bring activities on devices where tivoization might be an issue. On Saturday, 8 June 2013, Daniel Narvaez wrote: Yes I think it's very different because using GPLv2 would mean we can't use Apache licensed libraries, which are a big percentage of available js libraries. On Saturday, 8 June 2013, Gonzalo Odiard wrote: We already had this discussion two years ago, is the situation with the javascript activities different to need start this discussion again? Gonzalo On 06/14/2011 05:42 PM, Luke Faraone wrote: This is a vote to determine the suggestedlicense for future releases ofSugar. This poll will run from right now until Wed Jun 29 2011 at midnight UTC-4. Sorry for the late update; the reporting mechanism for our voting software temporarily broke. Summary: the winner was **GNU GPL version 3, or any later version**. ## Results Details ## 55 out of 217 eligible members voted, or a little more than ¼. The full results of this election ranked the candidates in order of preference (from most preferred to least preferred): 1. GNU GPL version 3, or any later version 2. GNU GPL version 2, or any later version 3. Don't know or don't care Each number in the table below shows how many times the candidate on the left beat the matching candidate on the top. The winner is on the top of the left column. v3 v2 DC v3 -- 34 37 v2 21 -- 42 DC 18 13 -- 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. Full details (and alternative election method calculations) are visible at the Selectricity page linked in the original voting ticket email. Thanks, Luke Faraone Sugar Labs, Systems âoe0/00:l...@sugarlabs.org I: lfaraone onirc.freenode.net http://irc.freenode.net/ On Fri, Jun 7, 2013 at 8:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Well permission to double license really. On Saturday, 8 June 2013, Daniel Narvaez wrote: Ugh one issue with Apache is that I think we would need to get permission to relicense the svg icons under apache from all the people that contributed to them. Do you think that will be possible? People that contributed but doesn't seem to be involved with the project anymore. Eben Eliason Marco Pesenti Gritti Tomeu Vizoso Still around Scott Ananian benzea erikos Martin Abente Walter Bender godiard Manuel Quinones From the git log of the icons dir. On Saturday, 8 June 2013, Daniel Narvaez wrote: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. On Saturday, 8 June 2013, Daniel Narvaez wrote: We really need to make a call here, we start to have a sizeable amount of code and the first release is near. I tend to think gplv2 is not an option because of the apache incompatibility. I would go for Apache if we want to avoid issues with anti-tivoization, otherwise gplv3. To point out a concrete problem we could have with gpl3... My understanding is that you could not ship an activity based on
