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 <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.com<javascript:_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 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 wi >> >> _______________________________________________ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org <javascript:_e({}, 'cvml', >> 'Sugar-devel@lists.sugarlabs.org');> >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> > -- Daniel Narvaez
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel