On Sat, 2014-01-25 at 19:07 +0100, Thomas Strobel wrote: > On Fri, 2014-01-24 at 21:51 -0200, Gustavo Sverzut Barbieri wrote: > > On Fri, Jan 24, 2014 at 7:57 PM, Thomas Strobel <ts...@cam.ac.uk> wrote: > > > On Fri, 2014-01-24 at 19:14 -0200, Gustavo Sverzut Barbieri wrote: > > >> this was on purpose. > > >> > > >> The recent authors (cedric, me, tom...) decided they didn't like BSD > > >> as the ancient and the license was hurting us as nobody gave back. > > >> Then when we created Eina to unify data types in ecore and evas, we > > >> proposed to do it in LGPL and people accepted, raster was okay with > > >> that and so we did. > > >> > > > > > > Thanks for the explanation. Just out of curiosity, did it help? I mean, > > > did you get more people to contribute back to the project now? > > > > I doubt all the companies that did contribute lots of resources would > > have done if it was bsd. It's hard to ensure the results of a change > > would have in the future, but companies would just ignore it because > > of license (ie: my company) to others that would likely keep private > > changes because they were allowed to. > > > > given the way big companies work, I doubt samsung would contribute > > everything they did if they didn't have to... it's a hard and painful > > process, they had to do, i guess they would just skip if they were > > allowed. > > > > Thanks! It was very interesting to follow the heated discussion about > this topic. It seems difficult to estimate the consequences of the > different licenses though. > > I just wonder what your intentions are for the future. Do you plan to > push everything towards LGPL? The BSD license would be perfectly fine > with doing so (same argument as used for moving certain parts of EFL to > LGPL already). Or are you hesitating because you want to keep a way to > move back to BSD? Looking at it from the outside (non-contributor so > far), it would be clearer to have one license only, or at least have the > less permissive license for the less fundamental parts (that is opposite > to how it is right now). From how the code is structured, the license > does not really matter at the moment as you can easily link and > integrate closed-source parts. But it would be nice to know where you're > heading to. > Or, is your intention to put a "price" onto not contributing back, but leaving the opportunity to do so? That is by asking e.g. companies who want to use EFL commercially to at least take the effort in keeping their closed-source parts separated and thus making it more cumbersome to manage. If so, nicely done! > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
