On Sun, 2014-01-26 at 09:31 +0900, Carsten Haitzler wrote: > On Sat, 25 Jan 2014 20:03:02 +0100 Thomas Strobel <ts...@cam.ac.uk> said: > > > 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! > > the intentions for the future is to merge efl. the split thing is just not > what > the vast majority of people (packagers, developers etc.) want. the vast > majority find it a major pain in the rear - a barier of entry, a hinderance to > learning etc. - so such a move ultimately will mean we compile into far fewer > library files. simple leagal necessity will be that efl as a whole becomes > lgpl > as that is the compatible superset of licenses. > > but actually we are raising the price of a fork. not by license - but by > motion. our merge of efl alone has effectively chopped off at the knees any > prior forks (except elementary). the cost of maintaing those just went up. > putting eo into everything also raised the price majorly. by simply moving > along so rapidly, a fork becomes a massive cost to maintain. giving back and > keping up is the only sensible option for anything other than a > flash-in-the-pan effort. and for flash-in-th-pan efforts... we do have a > license. :) > > there is a boundary for efl where you are free to plug in thins of any > license. > the api boundary. that means anything hat uses efl/elm's header files and > links > to the shared libs. this ALSO includes modules/plugns. you CAN provide closed > module additions/replacements. modules are intended to cover several uses - > moving shared lib dependencies of to an optional component only loaded on > demand, create the ability to compile efl once and once only with all featues > on and then split up package-wise your specific needs like x11 vs wayland so > only the modules relevant are installed, as well as to act as a unified api > wrapper to simplify internal code - eg to talk to something that loads images > with the single same api no matter the loader or format. >
Thanks for your clarifications! It's interesting to know that EFL is moving towards LGPL. It is a pity to have to watch you lowering the value of your code, especially if the the pace with which EFL is being developed makes a fork almost impossible anyway. But I'm very grateful EFL exists in the first place, thanks! :) ------------------------------------------------------------------------------ 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
