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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
