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
