Jorge Luis Zapata Muga wrote: > On Thu, Aug 7, 2008 at 3:21 AM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > >> On Wed, Aug 6, 2008 at 4:52 PM, Jorge Luis Zapata Muga >> <[EMAIL PROTECTED]> wrote: >> >>> You can't tell me that im wrong as i did eina and took the decisions >>> about it. I have to explain this as this totally wrong. Eina's attempt >>> was known, i already commented about it on irc and on ml, *with* >>> intention to get developers contribute to it, contribute not only on >>> the sense of coding it, but actually *using* it to have a common data >>> library. >>> >> You are wrong again, I can examine the evidence and draw conclusions >> and I'm perfectly capable of saying that I think you're wrong. You are >> repeating your opinion and drawing conclusions which are not founded >> by the arguments you present. >> >> You worked in a repository outside of the normal project. This means >> only developers that explicitly want to jump into your effort will >> follow the activity, you won't pick up work from the project members >> that don't sign on. How many E related side projects have you seen >> become heavily adopted before they went into CVS? I can't think of any >> except for maybe E-Live and that was primarily because it was well >> linked from E.org and was an entire distribution to help users try E. >> >> Myself, I did not follow eina outside CVS mainly because we have many >> people mention wanting to help with things that never come to >> fruition. I would not be surprised if others were in the same >> situation. I also did not see any statements from raster that he was >> willing to let evas depend on an external data type lib. Without that, >> there was not much point to another data structure lib as it would >> just be more duplication. >> > > Ok, now you *think* that im wrong, but again im not wrong, eina jumped > out from e cvs in the first place, the solution that was already on e > cvs was edata, so is not about following a project outside, is that > the project initially was on proto and the ml certificates it and > nobody contributed to it not even discussed when the stringshare lib > was presentead, those are facts, you can check the logs and the ml, is > all there. But as i have said and so do you, evas (raster) didnt want > a dependency library for data types but now he is ok with that, that's > what i meant with the adoption, he said it is good, now eina is good > for everyone, that is what has happened. > > >>>> Nothing to do with the >>>> license. Cedric may have been interested because it was LGPL, but most >>>> >>> Cedric was interested on the project by himself and because it was >>> technically good, i think having a common library for data types is >>> something we all agree. I think he will reply on this. And yes, the >>> license do has something to do with this, as *i* want it to be lgpl. >>> >> As I stated in another email, that's fine for you, but not necessarily >> fine for broader project. >> >> >>>> people I know of are interested because we can finally remove some >>>> redundant API's. >>>> >>> If so, why on the past two years, no interest on this library >>> (concept) has been shown? i even received comments like: ecore already >>> provides it and ecore means "core" so it should belong there and not >>> in evas/eet. kind of absurd, imho. >>> >> Because you were working in an external repository. By being outside >> CVS it was not really part of the project. E doesn't get a ton of >> developer attention as it is, and you expect an unknown experimental >> lib developed outside the project to get more attention? Also, you >> mentioned previously that it was already LGPL, if you're proposing the >> license "change" is the driving force for interest, how was there a >> change? >> > > As i said too many times, there was edata, this arguments are refered > to edata, not eina, you can think of eina on just the same > conceptually lib but developed from the base code of edata. So i > wasn't expecting developers on eina, i was expecting them on edata > when i created it, but none appeared, so the excuse of "it was outside > cvs" applies to eina, but im ok with that and never wanted to say the > other thing, what i meant is the "feedback" it has received, as edata > received none, eina also received none, until raster give a "go" and > the license has become an issue, those are facts, not opinions. > > And i have already stated on other mails, I *wanted* (it didnt have > any license) it to be lgpl but didnt add any license reference on the > code because if this was going to be included i wanted other opinions > and so i did, but the push from others developers and mine has made > eina to be lgpl no bsd. > > >> I don't really know where those comments came from so it's not up to >> me to defend them. >> >> >>>> Why don't you ask Peter since he's the other one you >>>> mention making some effort on it? >>>> >>> Peter already stated his POV on this, he said that he wont contribute, >>> so his stringshare code was respected with the bsd license on top of >>> the file. Did i do something wrong? what happens with edata when it >>> was on cvs, why he didnt put up his effort there and instead made a >>> new library? why he didnt contact me about eina on the beginning? I >>> respect his decision, but looks like mine isnt respected. >>> >> Assuming Peter contributed under the understanding that it was BSD >> licensed, then you're fine. Since eina didn't have a license in CVS, >> > > So now you say eina didnt have a license but before you said it was > lgpl, or at least that i made it lgpl before including on e cvs? > > >> or he may not have bothered to check since everything else is BSD, he >> probably assumed it was BSD. >> > > No, he didnt assumed that. I explicitly sent an email saying my will > about the library when he hadn't commit anything into eina yet, and he > already expressed his will, of not contributing code and not coding on > it, so i took the risk. The thing here is why should i care now (two > years later) for something that others didnt care back then? not > talking on eina directly, but edata as it predecessor. that's what i > argue when answering the consensus mail you sent me, you ask me for > consensus on a project where there is no consensus. > > >> It may not seem like it to you, but being in an external repository is >> a huge problem for something you want integrated into a bigger project >> and I think you're experience reinforces that. >> >> >>>> You are misquoting this argument. The argument is we can't easily >>>> inter-change code with LGPL because it's now a one way relationship. >>>> We can only put things INTO eina because if we take anything out, we >>>> have to use the LGPL or GPL. >>>> >>> True, so? i understand that having that flexibility is something you >>> are interested on, and i respect that; but i have a different vision >>> there, doing that is what e has exactly been doing with no real gain, >>> just moving/renaming and code things on a monolithic way; and i dont >>> like that approach. >>> >> Like you moved code from evas into eina? Evas is a large monolithic >> structure, and I agree that the data structures needed to be split >> out. There is otherwise not that much code shifting going on. What we >> do see here and there is a nice abstraction in a piece of code which >> then gets split out into a lib, and on occasion an abstraction that is >> really only useful in one case that gets moved into a different >> component. >> >> Here's a realistic example. What if I decide to use the memory pools >> API from eina in EWL, but we find evidence that the memory pools are >> actually worse in most use cases than the standard allocator (trust me >> this happens, I've seen it specifically with memory pools). If you >> remove it and break EWL, I can no longer use my discretion to pull >> that code into EWL specifically, even if EWL happens to be one of a >> few use cases that benefit from them. >> >> >>> Well, that's just a words game, you can call it unhealthy community, >>> but for me a community is exactly that the community has the power to >>> change how it operates, which in this case has been broken (with >>> eina's license) because i dont think this is a community. >>> >> Maybe this speaks more about your experience than the project as a >> whole. I certainly feel part of a community from years of working with >> good people that have treated each other with respect. I have >> regularly seen people come through and hurt the community by refusing >> to work with others or don't treat others with respect. >> >> Do you feel that every new person that comes to the project should be >> allowed to choose a new license? re-implement an existing component? >> >> Whether you try to dismiss what I have to say as "word games" or not, >> you are nowhere near arguing a strong reason that you should be able >> to impose a license change on the project. You are basically saying >> "This is what I want, so that's how it should be." And if you're >> listening to the people on this list, many of us only want one license >> in the project. >> >> Seeing as the point of eina was to unify the use of data structures >> and utility functions, this is a very fracturing decision. >> >> > > Indeed and i agree, i didnt expect that many mails regarding license changes. > > But look the new move to trac, suddenly everyone has to move to trac > and the people that has contributed to e wiki need to move their > pages, same thing for the bugs (which is something that not everyone > likes), what happens there? was there any consensus on that? who has > the power to do whatever he wants with e? raster? and if so, he might > also have the power to close the source of this, right? so i prefer to > keep it *always* free, is an itchy point, but blaming eina's license > for the fracturing of the e "community" is demagogy. >
He is free to fork the code and close it up, but that doesn't stop the rest of the community from pushing forward with what's there. The recent move to Trac/SVN was nothing that I hadn't expected to happen sooner or later. Many people, including users, disliked Bugzilla for many different reasons. It was also done in an effort to help clean up the website and hopefully make it easier to point users to information they need. As to all this work that you propose needs to happen, most of the MediaWiki content can be easily transferred over to Trac as well as Bugzilla bugs. There may need to be some manual tweaking, but for the most part this can be automated. This was also something that I believe raster was more forced into then a decision he made on his own. He made some compromises with what some people from the past have enjoyed and what most newer devs seem to want. So in reality, all he did was take the motivation to make the change and make it happen. If I hadn't ended up in the hospital this week I probably would have been transferring the wiki and bugs already. I still don't understand what about the BSD makes it not always free, you can't steal the code, the free code is always there. Even if raster wanted to, he could not just up and close the code. He would have to make a closed fork and develop it on his own or with others who agree to go that route. In that same thread, I don't expect a company to pay their employees to just give away everything for free if they are truely adding some value to the code that the open source community either cannot or doesn't have the desire to. Also, they will have a lot more time to add value since they are depending on the community to keep the base solid. If they give back, that's great, but not all companies can afford to do this and some may just need some time to get on their feet before they give back. The BSD license gives them this ability and offers them true freedom in their decisions and leaves the moral choice in their hands, not the hands of others. A company that chooses to give back out of choice is better then one that gives back because they are required to do so IMO. Also, by introducing an LGPL lib into the community to the point that our core BSD libs become dependent on it does hurt things. It's always been the assumption that our core libs will be BSD from the bottom up. E17 is also licensed BSD. If the lib was not core we didn't worry all that much about the license used, at least as a community. When it comes to the libs that we ship as our crowning achievements, having two licenses throughout is just going to drive companies insane. It complicates all the legalities involved and they then have to be extra careful not to touch any LGPL lib code. Also note how I said LGPL coming into the community and not LGPL in general. Generally any LGPL lib we depend on now is an indirect dep of another lib we depend on that is generally BSD or otherwise similarly licensed (best I can tell anyway). Some of the indirect deps like libC are not always GPL either as we are not (or should not) be dependent on a single implementation of this. After having looked into this more heavily I'm now even more concerned by having an LGPL as an immediate dep of Evas and Ecore, two of our lowest level libraries. > ------------------------------------------------------------------------- > 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
