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