Back to the original question... I don't intend to contribute to eina if it's not BSD. The main reason (beyond my personal preference) is that it is not consistent with the rest of the repository. This hurts our ability to shift code within the repository
If I write a nice abstraction in another lib, and decide it would be useful to share with others, I'm now forced to relicense it as LGPL if I move it to eina. Also, if there is an abstraction in eina that someone decides to remove, say it is too application specific but it would work nicely in another lib or app, they are now forced to relicense their code to be LGPL. So in my opinion, a license change would need to be project-wide, not one low-level component that should be widely accessible. Also, on the more technical side, I have some concerns about it being a direct port of either evas or ecore data types. Both have some issues I'd like to see solved if we're creating a new library. On Sat, Aug 2, 2008 at 6:59 PM, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > Hi all, as you all (most) know, eina has hit proto cvs. I think > several things have to be explained, references to eina's license, > code and so have appeared on different threads and honestly following > them all is very complicated and is also hard to actually decide > something, so it might be good if at some moment, someone can make a > summary of several opinions and just do a poll and decide on it. > Anyway, here is my summary: > > Objective: > Eina's original objective was to settle down the long-time discussion > about multiple data types, mainly ecore's and evas', it was an attempt > that, from what i've seen, several developers have agreed and have a > good will on this library; even the ecore's data types supporter > (eina's is currently based around evas data types). > > It has several subsystems in a very similar way to what ecore has, but > the main reason to not place ecore on the bottom of the software > dependency stack was because not every library built around our data > types wants to be "loopized" with ecore's main loop implementation, > but be some kind of agnostic to ecore, so gtk / qt / whatever can use > this libraries an fit their own loop manager on top of this low level > library. > > Evas is an example of such a thing (there are others), and no, > ecore-evas current double dependency is not the main problem eina > wants to solve, not even the original problem it wanted to solve. If > you place the efl stack, eina will be at the bottom, ecore on top of > it and so other libraries/apps that *need* some kind of main loop > handling, it can be summarized as "pull approach libraries" you pull > the state from it, instead of evas (and others libraries) where you > "push" the state (evas_render). > > License > As most of the code on efl-research project (and most of *my* code) it > does not have COPYING file, it was left out on purpose, basically to > be able to discuss this "license issue" with e developers. We all have > already argued about licensing and there are several respectable and > contrary point of views. I, as the original author of this library, > even if some of the code was taken from evas or ecore, wanted to > license the library as LGPL; but as i have already stated, this new > license has several considerations, *please* don't start a license > arguments, the other thread is for that, this one is to decide: > > 1. Relicensing eina as LGPL is possible and *does not* go against Evas > or Ecore license, BSD allows that as long as the third (author) clause > is respected and so it will be (in case eina's license finally gets > set to LGPL) > 2. What will be the reaction from developers that want BSD license? > from what i've deduced on IRC and ML, several of this developers > *won't* contribute to this library if it is not BSD, (please those > developers that think that this is point is for them, confirm or deny > this). In my opinion the current state of e developers is too small to > actually divide it based on the license they prefer; and of course > that argument "imposes" the license the library can be. So, the main > question on this point is: if it is LGPL are you going to contribute > to it? and, if it is LGPL are you going to *link" against this > library? > > > ps: i would like to discuss several eina's subsytems, but looks like > the license has to be solved first, so let's get it done, so we can > focus on the code. > > Best regards, > turran > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
