Jorge Luis Zapata Muga 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 > Not that I think my opinion is particularly relevant or that it will help in one direction or the other, but I'll just state it anyway:
I think there should be One License for The Enlightenment Project. I think the One License rule should be enforced strictly. If people have code they don't want to place under The License for The Enlightenment Project they should take it elsewhere. I'd prefer The Licence to be BSD. This means that if any part of The Enlightenment Project remains under BSD I will object to changing the license for any other part away from BSD or adding new sub-projects with a different license. My main reason is that I think the current situation where it is possible to move/copy code between apps and libs without having to worry about infection and license differences is good. If it is possible to obtain no objections to switching ALL of The Enlightenment Project to LGPL, ok then let's switch. However, I don't think there is any chance this is going to happen. I think it would be *really* nice soon to put an end to all this license talk for some time to come. /Kim ------------------------------------------------------------------------- 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
