Re: [E-devel] E CVS: proto/eina turran
Please find a way to stop bothering the community with this ridiculous load of crap, even if that means forking e. Hisham you are one of the prime reasons this community, or lack there of in your opinion, is having trouble. Your inability to work on a project where your ideas aren't always used/accepted has been a bruise to the community, etk being the perfect example. That really hurt the community, and the community has been split ever since into two groups that don't get along. You were splitting the community as far back as etk and now here you go trying to split it again by promising to raise hell until you get your way. Gustavo what makes you think you have authority, especially over the likes of Nathan? No matter how much current code you've done, it doesn't even come close to the amount of code that other long-term devs have done. You have provided your ideas to the community on the mailing list, and they were not universally accepted, tough, but thats the way a community works. Kudos that you get paid to work on this project and have more time currently to work on it, but that doesn't mean you get to butcher it how you want. Jorge, I thought perhaps you were on the right track when you sent an email getting opinions about which license to use, but now I see that was just a gimmick and you didn't even listen to the opinions. Most people in their right minds will not link against eina because it is lgpl and the rest of the libraries are bsd. I will not link against eina in my applications and I will not use any libs that link against it. This reply to this thread is just an opinion, and likely not a highly regarded one, but promising to persist with this war is the worst thing for the community, not the licensing. Please take your subjective ideals/desires elsewhere. --Stephen Houston - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
A decision has been made on this issue, so let this thread die. Whether we agree with the decision or not is up to us to act on as individuals now, and bringing it back to the list won't do any good but to fan further flames. On Tue, Aug 12, 2008 at 1:17 PM, Stephen Houston [EMAIL PROTECTED] wrote: Please find a way to stop bothering the community with this ridiculous load of crap, even if that means forking e. Hisham you are one of the prime reasons this community, or lack there of in your opinion, is having trouble. Your inability to work on a project where your ideas aren't always used/accepted has been a bruise to the community, etk being the perfect example. That really hurt the community, and the community has been split ever since into two groups that don't get along. You were splitting the community as far back as etk and now here you go trying to split it again by promising to raise hell until you get your way. Gustavo what makes you think you have authority, especially over the likes of Nathan? No matter how much current code you've done, it doesn't even come close to the amount of code that other long-term devs have done. You have provided your ideas to the community on the mailing list, and they were not universally accepted, tough, but thats the way a community works. Kudos that you get paid to work on this project and have more time currently to work on it, but that doesn't mean you get to butcher it how you want. Jorge, I thought perhaps you were on the right track when you sent an email getting opinions about which license to use, but now I see that was just a gimmick and you didn't even listen to the opinions. Most people in their right minds will not link against eina because it is lgpl and the rest of the libraries are bsd. I will not link against eina in my applications and I will not use any libs that link against it. This reply to this thread is just an opinion, and likely not a highly regarded one, but promising to persist with this war is the worst thing for the community, not the licensing. Please take your subjective ideals/desires elsewhere. --Stephen Houston - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Fri, Aug 8, 2008 at 5:51 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Fri, Aug 8, 2008 at 7:39 AM, Enlightenment CVS [EMAIL PROTECTED] wrote: +EAPI void eina_error_print(Eina_Error_Level level, const char *file, const char *fnc, int line, const char *fmt, ...) { va_list args; va_start(args, fmt); - _error_print(level, file, fnc, line, fmt, args); + if (level = _error_level) + _print_cb(level, file, fnc, line, fmt, _print_cb_data, args); va_end(args); +} Let's try to avoid this useless nesting and also making it more optimized, in this case, by using: if (premature-exit-condition) return; real-code. Of course it should be like that, thanks for pointing it out, for small code like this please commit the fix directly, if you have time of course Regards in this case you'd avoid va_start()/va_end(): if (level _error_level) return; va_start(args, fmt); _print_cb(level, file, fnc, line, fmt, _print_cb_data, args); va_end(args); code is simpler, can be smaller if you need to add more things inside va_start/end -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Fri, Aug 08, 2008 at 12:51:18PM -0300, Gustavo Sverzut Barbieri wrote: On Fri, Aug 8, 2008 at 7:39 AM, Enlightenment CVS [EMAIL PROTECTED] wrote: +EAPI void eina_error_print(Eina_Error_Level level, const char *file, const char *fnc, int line, const char *fmt, ...) { va_list args; va_start(args, fmt); - _error_print(level, file, fnc, line, fmt, args); + if (level = _error_level) + _print_cb(level, file, fnc, line, fmt, _print_cb_data, args); va_end(args); +} Let's try to avoid this useless nesting and also making it more optimized, in this case, by using: if (premature-exit-condition) return; IMHO, if possible exiting early, as you suggest, almost always leads to cleaner code. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Sat, Aug 9, 2008 at 3:37 AM, Simon Horman [EMAIL PROTECTED] wrote: On Fri, Aug 08, 2008 at 12:51:18PM -0300, Gustavo Sverzut Barbieri wrote: On Fri, Aug 8, 2008 at 7:39 AM, Enlightenment CVS [EMAIL PROTECTED] wrote: +EAPI void eina_error_print(Eina_Error_Level level, const char *file, const char *fnc, int line, const char *fmt, ...) { va_list args; va_start(args, fmt); - _error_print(level, file, fnc, line, fmt, args); + if (level = _error_level) + _print_cb(level, file, fnc, line, fmt, _print_cb_data, args); va_end(args); +} Let's try to avoid this useless nesting and also making it more optimized, in this case, by using: if (premature-exit-condition) return; IMHO, if possible exiting early, as you suggest, almost always leads to cleaner code. ACK... using this and also writing smaller functions would help a lot (even more because you can easily use this technique). /me looks at raster. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Fri, Aug 8, 2008 at 7:39 AM, Enlightenment CVS [EMAIL PROTECTED] wrote: +EAPI void eina_error_print(Eina_Error_Level level, const char *file, const char *fnc, int line, const char *fmt, ...) { va_list args; va_start(args, fmt); - _error_print(level, file, fnc, line, fmt, args); + if (level = _error_level) + _print_cb(level, file, fnc, line, fmt, _print_cb_data, args); va_end(args); +} Let's try to avoid this useless nesting and also making it more optimized, in this case, by using: if (premature-exit-condition) return; real-code. in this case you'd avoid va_start()/va_end(): if (level _error_level) return; va_start(args, fmt); _print_cb(level, file, fnc, line, fmt, _print_cb_data, args); va_end(args); code is simpler, can be smaller if you need to add more things inside va_start/end -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
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
Re: [E-devel] E CVS: proto/eina turran
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
Re: [E-devel] E CVS: proto/eina turran
On Thu, Aug 7, 2008 at 7:40 AM, Nick Hughart [EMAIL PROTECTED] wrote: 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. Some people don't want their code forked off and closed away and want all contributions to come back. This is the difference. 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. This is a decision that was made around 10 years ago, we're working on changing that. 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. No one expects anything to happen over the course of a single night, week, or month. Its going to take some time, and we're going to keep at it until its done. -- Hisham Mardam Bey http://hisham.cc/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Actually I thought it was BSD licensed. I didn't expect that Trojan horse tactic. Only after Vincent has asked me if it is ok for me to switch to LGPL I realized that i contributed to a proprietary project. Can you develop why a project using LGPL is a proprietary project ? For me, a proprietary project is a project whose code is not available (whatever i have to pay or not for that project). Am I wrong ? Vincent - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Vincent Torri schrieb: Actually I thought it was BSD licensed. I didn't expect that Trojan horse tactic. Only after Vincent has asked me if it is ok for me to switch to LGPL I realized that i contributed to a proprietary project. Can you develop why a project using LGPL is a proprietary project ? For me, a proprietary project is a project whose code is not available (whatever i have to pay or not for that project). Am I wrong ? It didn't have a license. So it was proprietary. Peter - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Hisham Mardam Bey wrote: On Thu, Aug 7, 2008 at 7:40 AM, Nick Hughart [EMAIL PROTECTED] wrote: 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. Some people don't want their code forked off and closed away and want all contributions to come back. This is the difference. This sounds a lot like having your cake and eating it too heh. LGPL only stops the company from modifying the lib anyway, any other work they do goes towards their lib. What if they add a bunch of worthless code that only adds hooks to an external binary blob or something? Is that code any use then? I think this limitation is so easily worked around as to make it completely pointless. 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. This is a decision that was made around 10 years ago, we're working on changing that. Is there a reason to change it? Has the original decision led to problems? Is switching to the LGPL going to instantly solve our community issues or is it just going to cause more animosity between the developers? A divided community doesn't exactly help get corporate interest brewing either. Plus any company looking into the EFL now may just go elsewhere because they may perceive that the license will change and thus cause them plenty of issues in the long run. 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. No one expects anything to happen over the course of a single night, week, or month. Its going to take some time, and we're going to keep at it until its done. So you're assuming everyone will just give up and accept the LGPL? I highly doubt this will happen so have fun fighting. It's a choice based on ideals. Some of us are not worried about what a company does with our code as we feel like furthering the development of software in any way possible. Getting paid to code software tends to lead to more code generation and if they do decide to give back, that's great, but even if they don't they will have hopefully created a good product that consumers can use based on code that others can help improve. If they completely fork the code and modify it heavily then they've added enough value that it may not even be the same code anymore and possibly not even the same idea. Regardless of the fact that forking to these degree is no small undertaking. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] E CVS: proto/eina turran
On Thu, Aug 7, 2008 at 9:30 AM, Nick Hughart [EMAIL PROTECTED] wrote: Some people don't want their code forked off and closed away and want all contributions to come back. This is the difference. This sounds a lot like having your cake and eating it too heh. LGPL only stops the company from modifying the lib anyway, any other work they do goes towards their lib. What if they add a bunch of worthless code that only adds hooks to an external binary blob or something? Is that code any use then? I think this limitation is so easily worked around as to make it completely pointless. 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. This is a decision that was made around 10 years ago, we're working on changing that. Is there a reason to change it? Has the original decision led to problems? Is switching to the LGPL going to instantly solve our community issues or is it just going to cause more animosity between the developers? A divided community doesn't exactly help get corporate interest brewing either. Plus any company looking into the EFL now may just go elsewhere because they may perceive that the license will change and thus cause them plenty of issues in the long run. 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. No one expects anything to happen over the course of a single night, week, or month. Its going to take some time, and we're going to keep at it until its done. So you're assuming everyone will just give up and accept the LGPL? I highly doubt this will happen so have fun fighting. It's a choice based on ideals. Some of us are not worried about what a company does with our code as we feel like furthering the development of software in any way possible. Getting paid to code software tends to lead to more code generation and if they do decide to give back, that's great, but even if they don't they will have hopefully created a good product that consumers can use based on code that others can help improve. If they completely fork the code and modify it heavily then they've added enough value that it may not even be the same code anymore and possibly not even the same idea. Regardless of the fact that forking to these degree is no small undertaking. Ideals, true, our ideals point in the direction of the LGPL. This discussion is really not going anywhere. I'm not going to waste time replying anymore. Our goals and intentions are clear. We're working towards them and will accomplish what we set out to do. Those who choose to stagnate and bind themselves to the previous state of the project may do so, we're proceeding forward by writing code and making changes. -- Hisham Mardam Bey http://hisham.cc/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Hisham Mardam Bey wrote: On Thu, Aug 7, 2008 at 9:30 AM, Nick Hughart [EMAIL PROTECTED] wrote: Some people don't want their code forked off and closed away and want all contributions to come back. This is the difference. This sounds a lot like having your cake and eating it too heh. LGPL only stops the company from modifying the lib anyway, any other work they do goes towards their lib. What if they add a bunch of worthless code that only adds hooks to an external binary blob or something? Is that code any use then? I think this limitation is so easily worked around as to make it completely pointless. 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. This is a decision that was made around 10 years ago, we're working on changing that. Is there a reason to change it? Has the original decision led to problems? Is switching to the LGPL going to instantly solve our community issues or is it just going to cause more animosity between the developers? A divided community doesn't exactly help get corporate interest brewing either. Plus any company looking into the EFL now may just go elsewhere because they may perceive that the license will change and thus cause them plenty of issues in the long run. 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. No one expects anything to happen over the course of a single night, week, or month. Its going to take some time, and we're going to keep at it until its done. So you're assuming everyone will just give up and accept the LGPL? I highly doubt this will happen so have fun fighting. It's a choice based on ideals. Some of us are not worried about what a company does with our code as we feel like furthering the development of software in any way possible. Getting paid to code software tends to lead to more code generation and if they do decide to give back, that's great, but even if they don't they will have hopefully created a good product that consumers can use based on code that others can help improve. If they completely fork the code and modify it heavily then they've added enough value that it may not even be the same code anymore and possibly not even the same idea. Regardless of the fact that forking to these degree is no small undertaking. Ideals, true, our ideals point in the direction of the LGPL. This discussion is really not going anywhere. I'm not going to waste time replying anymore. Our goals and intentions are clear. We're working towards them and will accomplish what we set out to do. Those who choose to stagnate and bind themselves to the previous state of the project may do so, we're proceeding forward by writing code and making changes. Glad to see that everyone is still under the illusion that the license is the problem when that has little to nothing to do with it. It has to do with things like this that cause the community to be unable to compromise and split off. Thank you for proving my point for me, made things much easier. Sounds a lot like Obama's campaign, making a lot of change just for the sake of changing. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Peter Wehrfritz wrote: Jorge Luis Zapata Muga schrieb: 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. Yes, you weren't the only one how wanted to have a data type lib, but E had a dep-freeze, if you haven't forgot. And it was clear that ecore would have been split after the release of E17. After e_dbus and efreet where added as a direct dep of e17, raster seems to have changed his mind. But that happen some weeks ago. So there wasn't really a reason for a data type lib before. And after that i presented edt as a beginning to put the data types into a single standalone lib. But you insisted that it must be eina. Now I understand why. Before the license discussion I thought it is because of the indentation or the name, why it must be eina and not something else. 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. Actually I thought it was BSD licensed. I didn't expect that Trojan horse tactic. Only after Vincent has asked me if it is ok for me to switch to LGPL I realized that i contributed to a proprietary project. I am using e since the beginning and find that this discussion about this license issue will never stop. From my user point of view (which is probably meaningless), I also feel that this discussion was introduced in a trojan way and discussing about it will not give the solution to this problem. I will not stop using e because it is under lgpl or anything else but from a user point of view I wish to see coherence in the project, i.e., that the efl libs and e17 are under the same license, that's all. I understand the arguments in favor of (or against) lgpl but I do not think that changing license will solve the diverse problems that the project has. It is a not a divide and conquer algorithm that the project needs but probably some consensus. One of them is to stop this flame war about license. This discussion does not give good signs to potential users. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link other code with the library, you must provide +complete object files to the recipients, so that they can relink them +with the library after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + We protect your rights with a two-step method: (1) we copyright the +library, and (2) we offer you this license, which gives you legal +permission to copy, distribute and/or modify the library. + + To protect each distributor, we want to make it very clear that +there is no warranty for the free library. Also, if the library is +modified by someone else and passed on, the recipients should know +that what they have is not the original version, so that the original +author's reputation will not be affected by problems that might be +introduced by others. + + Finally, software patents pose a constant threat to the existence of +any free program. We wish to make sure that a company cannot +effectively restrict the users of a free program by obtaining a +restrictive license from a patent holder. Therefore, we insist that +any patent license obtained for a version of the library must be +consistent with the full freedom of use specified in this license. + + Most GNU software, including some libraries, is covered by the +ordinary GNU General Public License. This license, the GNU Lesser +General Public License, applies to certain designated libraries, and +is quite different from the ordinary General Public License. We use +this license for certain libraries in order to permit linking those +libraries into non-free programs. + + When a program is linked with a library, whether statically or using +a shared library, the combination of the two is legally speaking a +combined work, a derivative of the original library. The ordinary +General Public License therefore permits such linking only if the +entire combination fits its criteria of freedom. The Lesser
Re: [E-devel] E CVS: proto/eina turran
Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Enlightenment CVS wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE +Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link other code with the library, you must provide +complete object files to the recipients, so that they can relink them +with the library after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + We protect your rights with a two-step method: (1) we copyright the +library, and (2) we offer you this license, which gives you legal +permission to copy, distribute and/or modify the library. + + To protect each distributor, we want to make it very clear that +there is no warranty for the free library. Also, if the library is +modified by someone else and passed on, the recipients should know +that what they have is not the original version, so that the original +author's reputation will not be affected by problems that might be +introduced by others. + + Finally, software patents pose a constant threat to the existence of +any free program. We wish to make sure that a company cannot +effectively restrict the users of a free program by obtaining a +restrictive license from a patent holder. Therefore, we insist that +any patent license obtained for a version of the library must be +consistent with the full freedom of use specified in this license. + + Most GNU software, including some libraries, is covered by the +ordinary GNU General Public License. This license, the GNU Lesser +General Public License, applies to certain designated libraries, and +is quite different from the ordinary General Public License. We use +this license for certain libraries in order to permit linking those +libraries into non-free programs. + + When a program is linked with a library, whether statically or using +a shared library, the combination of the two is legally speaking a +combined work, a derivative of the original library. The ordinary +General Public License therefore permits such linking only if the +entire combination fits its criteria of freedom. The Lesser General +Public License permits more lax criteria for linking other code with +the library. + + We call
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
We don't want the ability to cross-pollinate code with those projects and they are SEPARATE PROJECTS. The goal of eina was to unify around one shared data lib, so why would we not be using eina? On Wed, Aug 6, 2008 at 3:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I hate to reiterate over whats already been said, but just in case you've forgotten, here you go: That library is not a big one, it's not the most powerful lib on earth. Just a data type lib. You do not want to help, well, if you don't like LGPL, why not. But not linking against it, it's completely crazy. I won't link against it because it's an internal E library that isn't BSD. The rest of the stack is BSD and anything from the E project (at least core stuff) could be taken by a company and worked on internally. Suddenly there are pieces which require separate licensing and contribution requirements. Feels wrong. Does that mean that you also don't link against any lgpl (or other licence that is not like BSD or MIT) lib that exist ? No, it doesn't. Those aren't EFL projects. We have them marked as a dependency and I don't code for them. I may submit bugs and such but they aren't a big part of my work. I want to be able to take my work at some point and make modifications that aren't open if it comes to that. Why should I have to give up my ability to take my code and do what I want with it? (And, I know I can just re-license my code but in general it's been worked on my many, many, people so I can't just take it that way) dan Also, there have been several emails about the need to keep the licensing consistent within the project (from Kim, Luchezar, Andreas, etc). - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina's ideas hasn't been around for short time, i started this topic two years ago, even did a poll and added edata into cvs, the truth is that i created efl-research (some kind of a fork) to elaboroate the ideas i had, and then, include them into e cvs. But the consensus your quoting has never existed on this project, never; i think most of us will agree on this, everybody is following their own needs and goals on what they want things to be. Every time i've tried to push some discussion on some ideas or development changes it has lead to /dev/null and nobody has been interested on anything other one was/is doing on e cvs. So this consensus is just an hypothetical consensus on a project which hasnt. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. Regards On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 5:21 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: We don't want the ability to cross-pollinate code with those projects and they are SEPARATE PROJECTS. The goal of eina was to unify around one shared data lib, so why would we not be using eina? Because you don't like its license? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. Nathan, E *is* an unhealthy community. To be honest, E is not even a community. We are nothing more than a group of people working on their own little projects in a shared CVS repository. Look at the state of any active EFL project. We rarely have more than a single or two developers contributing to a project at any one point, and most of the time, the count is zero. Granted we're a small group, why does no one spend time fixing E17's bugs so we can roll it out the door instead of working on random bits here and there? No interest, maybe... The point is though, we're never trying to help each other in developing anything. Everyone cares about their own sub-projects and we rarely have any E-wide planning or any focused development on a single part because it will benefit us as a single community. -- Hisham Mardam Bey http://hisham.cc/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - 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=100url=/ ___ 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=100url=/ ___ 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
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 16:22 -0400, Jaime Thomas wrote: On Wed, Aug 6, 2008 at 4:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I hate to reiterate over whats already been said, but just in case you've forgotten, here you go: That library is not a big one, it's not the most powerful lib on earth. Just a data type lib. You do not want to help, well, if you don't like LGPL, why not. But not linking against it, it's completely crazy. I won't link against it because it's an internal E library that isn't BSD. The rest of the stack is BSD and anything from the E project (at least core stuff) could be taken by a company and worked on internally. Suddenly there are pieces which require separate licensing and contribution requirements. Feels wrong. Well that's quite close-minded. I don't agree to have different libraries for different libs within E (and I presume eina will take over from evas and ecore), but refusing to link to an LGPL library ... Well, if you want to make your life difficult, be my guest, but don't presume that everyone else does. Some of us just want to code, not go into the politics of code itself. Does that mean that you also don't link against any lgpl (or other licence that is not like BSD or MIT) lib that exist ? No, it doesn't. Those aren't EFL projects. We have them marked as a dependency and I don't code for them. I may submit bugs and such but they aren't a big part of my work. I want to be able to take my work at some point and make modifications that aren't open if it comes to that. Why should I have to give up my ability to take my code and do what I want with it? (And, I know I can just re-license my code but in general it's been worked on my many, many, people so I can't just take it that way) Are eina and etk your work? Take whatever you want from ewl and close it, it's your work, and you are certainly free to do so. Also, even LGPL can't force you to release your modifications, if the result is not public anyway (if you keep it in your basement, no one will care). Again, while it is bothersome that now we have to deal with multiple licenses, no one is forcing you to change to lgpl. dan Also, there have been several emails about the need to keep the licensing consistent within the project (from Kim, Luchezar, Andreas, etc). - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - 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=100url=/ ___ 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=100url=/
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. Mike dancingeek - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:45 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? Stop mis-characterizing statements. See my other reply about code interactions between parts of the project. On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - 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=100url=/ ___ 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
Re: [E-devel] E CVS: proto/eina turran
Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish);
Re: [E-devel] E CVS: proto/eina turran
Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? A gun has been put to the head of EWL now that it could potentially have an LGPL lib underneath it and thus bounding companies to either make cumbersome workarounds or in general make our community look like it can't make up it's mind (which probably isn't far from the truth at this point). On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:41 PM, Hisham Mardam Bey [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 4:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. Nathan, E *is* an unhealthy community. To be honest, E is not even a community. We are nothing more than a group of people working on their own little projects in a shared CVS repository. Look at the state of any active EFL project. We rarely have more than a single or two developers contributing to a project at any one point, and most of the time, the count is zero. Duh? And how does this do anything but hurt that loose affiliation even more? We now have a component that set of components that have become code tarpits from the rest of the project. Code can go in, but never come back out. Granted we're a small group, why does no one spend time fixing E17's bugs so we can roll it out the door instead of working on random bits here and there? No interest, maybe... The point is though, we're never trying to help each other in developing anything. Everyone cares about their own sub-projects and we rarely have any E-wide planning or any focused development on a single part because it will benefit us as a single community. We're all scratching our own itches as they come up. This is off-topic from the discussion though. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
I'm a Summer of Code student this year (so, not a /real/ E developer), and I was planning on keeping my head entirely out of this conversation, but each email makes that more and more difficult. So I've decided to express my _opinion_ on the matter of the E community (I'm have no preference in the license wars, and I will *not* choose a side). I've come to realize that the E community might not be as healthy as it appears from the outside; it certainly isn't as /large/ as it appears, nor as large as it would need to be in order to sustain a codebase of this size and expand its user base (as I assume one of the goals of the project is). However, it is my opinion that this is, in fact, *not* a license issue, nor a quality issue, or anything of that matter - the simple fact is, you *are* losing potential developers with arguments like this (and the rest from weeks past). They notice the amount of time the 'community' spends on things like this (among other issues), and move on to other projects. I know this, because I know a handful of said developers, and the fact that they decided not to work on E saddens me, but I cannot find fault in their argument; I'm sorry. Anyway - here's to a speedy resolution of this, and millions more lines of working, usable, use*ful* code. Tim - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:48 -0500, Nick Hughart wrote: Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? A gun has been put to the head of EWL now that it could potentially have an LGPL lib underneath it and thus bounding companies to either make cumbersome workarounds or in general make our community look like it can't make up it's mind (which probably isn't far from the truth at this point). This isn't meant as an offense, and IANAL, BUT how is LGPL restricting for companies exactly? They can use the library, and they can still keep their proprietary code too. The company I work for uses LGPL libraries, and there were never 'cumbersome workarounds' involved. On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - This SF.Net email is
Re: [E-devel] E CVS: proto/eina turran
Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. I wouldn't be so quick to make that assumption, I can recall many cases over ideas being stolen, mainly patents. Proving to a 50 year old judge who's never touched a computer that the code is identical with different words is incredibly easy and experts are paid for their testimony, so... On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 16:54 -0400, Timothy P. Horton wrote: I'm a Summer of Code student this year (so, not a /real/ E developer), and I was planning on keeping my head entirely out of this conversation, but each email makes that more and more difficult. So I've decided to express my _opinion_ on the matter of the E community (I'm have no preference in the license wars, and I will *not* choose a side). I've come to realize that the E community might not be as healthy as it appears from the outside; it certainly isn't as /large/ as it appears, nor as large as it would need to be in order to sustain a codebase of this size and expand its user base (as I assume one of the goals of the project is). However, it is my opinion that this is, in fact, *not* a license issue, nor a quality issue, or anything of that matter - the simple fact is, you *are* losing potential developers with arguments like this (and the rest from weeks past). They notice the amount of time the 'community' spends on things like this (among other issues), and move on to other projects. I know this, because I know a handful of said developers, and the fact that they decided not to work on E saddens me, but I cannot find fault in their argument; I'm sorry. Anyway - here's to a speedy resolution of this, and millions more lines of working, usable, use*ful* code. Tim And that is really THE saddest part of all this commotion. E isn't a community as Hisham said, not many people use it or its libraries (are there even any isvs using ewl or etk?). And instead of people doing what they like (which is in this case, coding), suddenly the shit hit the political fan. - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 16:00 -0500, Nick Hughart wrote: Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. I wouldn't be so quick to make that assumption, I can recall many cases over ideas being stolen, mainly patents. Proving to a 50 year old judge who's never touched a computer that the code is identical with different words is incredibly easy and experts are paid for their testimony, so... True, but patents != copyright. Totally different concept, totally different judges. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:55 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. You mean like EWD was? Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. Only if you are reimplementing it. You can't re-use any of the code from the original if you want to BSD license it. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + +
Re: [E-devel] E CVS: proto/eina turran
Viktor Kojouharov wrote: On Wed, 2008-08-06 at 16:00 -0500, Nick Hughart wrote: Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. I wouldn't be so quick to make that assumption, I can recall many cases over ideas being stolen, mainly patents. Proving to a 50 year old judge who's never touched a computer that the code is identical with different words is incredibly easy and experts are paid for their testimony, so... True, but patents != copyright. Totally different concept, totally different judges. They're all old and oblivious, doesn't matter which court it is heh. And given the RIAA copyright cases, who knows how copyright will come into play. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 -
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:54 PM, Timothy P. Horton [EMAIL PROTECTED] wrote: I'm a Summer of Code student this year (so, not a /real/ E developer), and I was planning on keeping my head entirely out of this conversation, but each email makes that more and more difficult. So I've decided to express my _opinion_ on the matter of the E community (I'm have no preference in the license wars, and I will *not* choose a side). I've come to realize that the E community might not be as healthy as it appears from the outside; it certainly isn't as /large/ as it appears, nor as large as it would need to be in order to sustain a codebase of this size and expand its user base (as I assume one of the goals of the project is). However, it is my opinion that this is, in fact, *not* a license issue, nor a quality issue, or anything of that matter - the simple fact is, you *are* losing potential developers with arguments like this (and the rest from weeks past). They notice the amount of time the 'community' spends on things like this (among other issues), and move on to other projects. I know this, because I know a handful of said developers, and the fact that they decided not to work on E saddens me, but I cannot find fault in their argument; I'm sorry. Anyway - here's to a speedy resolution of this, and millions more lines of working, usable, use*ful* code. Thanks Tim, well stated. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:46 PM, Mike Rutter [EMAIL PROTECTED] wrote: On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Mike dancingeek - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:46 PM, Mike Rutter [EMAIL PROTECTED] wrote: On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Given this information, why did you decide to even contribute to the EFL. Did you think that having multiple licenses would be fine with everyone? Mike dancingeek - 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. 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. 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. 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. 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. The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. 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. Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. 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. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 11:37 PM, Nick Hughart [EMAIL PROTECTED] wrote: Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:46 PM, Mike Rutter [EMAIL PROTECTED] wrote: On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Given this information, why did you decide to even contribute to the EFL. Did you think that having multiple licenses would be fine with everyone? Looks like it isnt fine with everyone, but i (and the others devs that want to have the code licensed under lgpl) think that a change needs to be done, maybe the license is not the best thing for everyone, but is a push we are going forward, at least with *our* code. From my personal point of view, I could have kept the code under the google code project and continue there and never give back code into e cvs, but it would have been unfair for the whole project and because others devs wanted that code *in*, so do i. Why contributing to the EFL? do i have to answer that? Having a library lgpl and linking against it, doesnt affect you unless you want to move code around and dont want to license yours as lgpl, which i doubt that having a good design means moving the code around. Mike dancingeek - 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. 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. 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. 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. Ecore is going to be split and thus ecore_data will be a separate library and was going to house all the datatypes, this shows how you've ignored or just don't understand the plans of the rest of the community. Ecore should not depend on Evas, Ecore_Evas should be split out now and this problem would be mostly moot as the circular dep would not exist and evas data types could be moved to ecore_data or merged to create new data types. Your effort is fine, your choice to make it LGPL may just make it useless in the end. If this is the route you want to go, then you'll have to deal with the consequences. On that same thread, can you honestly say that having a random LGPL lib that all these BSD libs depend on in a heavy way not concerning to anyone looking at the EFL? They may stay away just for fear of it all becoming LGPL and them being unable to update their forks. 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. Well all of the people who are contributing to eina showed no interest before. Since eina hit cvs people have been contributing to it with the intent of making it LGPL the whole time. Saying otherwise seems like a big lie to me as there really wasn't any thought put into the ramifications. Just because the people who like the LGPL tend to have more time to contribute doesn't mean it makes eina any better then the other efforts. You're making assumptions that cannot be made with your limited insight into the project. And if he would have put his effort into eina all his code would now be LGPL or rewritten to make it so, so that argument is pointless. Plus he also has obligations elsewhere and eina was not in E's repo so it wasn't really a good target given everyone was unsure of it's success. The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do
Re: [E-devel] E CVS: proto/eina turran
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. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Imagine our License page on our website: Well, some of our core libraries (evas, ecore...) are licensed under the BSD license, but some others are LGPL'd. This will only frustrate and confuse newcomers. Nobody cares if BSD is comfortable for your or anyone else's company, this is our current license and raster's 10 years arguments on GPL - BSD are still valid and good. Plus, again, we just can't relicense those libraries, you know the reasons. You guys are just doing mistakes and all this is a huge bullshit that frustrates both developers and users. See, Dan already left... A man with a huge contribution to the whole project. You want to make someone else leave? I think a lot of people will support me here. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Thu, Aug 7, 2008 at 12:06 AM, Nick Hughart [EMAIL PROTECTED] wrote: Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. 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. 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. 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. Ecore is going to be split and thus ecore_data will be a separate library and was going to house all the datatypes, this shows how you've ignored or just don't understand the plans of the rest of the community. Ecore should not depend on Evas, Ecore_Evas should be split out now and this problem would be mostly moot as the circular dep would not exist and evas data types could be moved to ecore_data or merged to create new data types. The above paragraph exactly shows how far you are from the real problem. *I* did the above plan, you are just repeating the words as if you actually know them, i did the poll with the developers asking what modules of ecore should be split, and ecore_data was not elected on that time to be split. The evas / ecore circular problem (ecore_evas) showed up when we want to have support for ecore based libs in evas, specially to allow remote engines (evoak's approach, do you remember?) so please, dont tell me things that i already said two years ago and nothing has done on that way. Please. Your effort is fine, your choice to make it LGPL may just make it useless in the end. If this is the route you want to go, then you'll have to deal with the consequences. On that same thread, can you honestly say that having a random LGPL lib that all these BSD libs depend on in a heavy way not concerning to anyone looking at the EFL? They may stay away just for fear of it all becoming LGPL and them being unable to update their forks. 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. Well all of the people who are contributing to eina showed no interest before. Since eina hit cvs people have been contributing to it with the intent of making it LGPL the whole time. Saying otherwise seems like a big lie to me as there really wasn't any thought put into the ramifications. Just because the people who like the LGPL tend to have more time to contribute doesn't mean it makes eina any better then the other efforts. You're making assumptions that cannot be made with your limited insight into the project. And if he would have put his effort into eina all his code would now be LGPL or rewritten to make it so, so that argument is pointless. Plus he also has obligations elsewhere and eina was not in E's repo so it wasn't really a good target given
Re: [E-devel] E CVS: proto/eina turran
Luchezar Petkov wrote: 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. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Imagine our License page on our website: Well, some of our core libraries (evas, ecore...) are licensed under the BSD license, but some others are LGPL'd. This will only frustrate and confuse newcomers. Nobody cares if BSD is comfortable for your or anyone else's company, this is our current license and raster's 10 years arguments on GPL - BSD are still valid and good. Plus, again, we just can't relicense those libraries, you know the reasons. You guys are just doing mistakes and all this is a huge bullshit that frustrates both developers and users. See, Dan already left... A man with a huge contribution to the whole project. You want to make someone else leave? I think a lot of people will support me here. Click here for great computer networking solutions! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMTAkyxiJnXDPUom5FxrSAmYldmm0e7sS5Rhm5lOczjV7/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: 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. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 7:29 PM, Luchezar Petkov [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel As a naught but a simple E user and occasional irc-lurker I have kept out of these sorts of discussions. This one however IMO is out of hand. Luchezar Petkov is 100% correct, please read his words above and take them into account. This sort of issue is entirely unworthy of a 50 post war. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Jose Gonzalez wrote: Luchezar Petkov wrote: 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. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. What difference in opinion is there in the core libs. The core libs have always been defined as those libs used by E. By this definition, EWL, ETK, etc are not core libs. They do however depend on these core libs in some way. The reason for all the inconsistency in the community is due to things like this. Someone tends to complain about something without good reasons to be doing so and just goes off and does their own thing instead of contributing back to the original effort. There are cases when this is fine such as some incredibly bad unfinished start of code from a dev who has completely left. In that case there is cause to start a new effort and this has been done a few times in the past. There are cases however where people wouldn't compromise and it's lead to fracture. Not saying one side or the other was right, just saying that there tends to be a lack of compromise and maybe that's good since we have been able to keep things lean and light till now. Sometimes compromise just leads things down the wrong path and if the authors of a lib feel that a compromise cannot be reached then that's their choice as the initial developers of that lib. They have a say in what hits mainline. So maybe we just don't feel like polluting our code with certain things just to please people in the short term and instead we actually weigh their suggestions against our goals and decide whether their contribution is helpful in that cause. Some people don't take rejection well. Are we elitist or just realistic about what we want? I find that too many people are too willing to accept shit these days and not ask questions... Imagine our License page on our website: Well, some of our core libraries (evas, ecore...) are licensed under the BSD license, but some others are LGPL'd. This will only frustrate and confuse newcomers. Nobody cares if BSD is comfortable for your or anyone else's company, this is our current license and raster's 10 years arguments on GPL - BSD are still valid and good. Plus, again, we just can't relicense those libraries, you know the reasons. You guys are just doing mistakes and all this is a huge bullshit that frustrates both developers and users. See, Dan already left... A man with a huge contribution to the whole project. You want to make someone else leave? I think a lot of people will support me here. Click here for great computer networking solutions! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMTAkyxiJnXDPUom5FxrSAmYldmm0e7sS5Rhm5lOczjV7/ - 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=100url=/ ___ 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
Re: [E-devel] E CVS: proto/eina turran
Zachary Goldberg wrote: On Wed, Aug 6, 2008 at 7:29 PM, Luchezar Petkov [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel As a naught but a simple E user and occasional irc-lurker I have kept out of these sorts of discussions. This one however IMO is out of hand. Luchezar Petkov is 100% correct, please read his words above and take them into account. This sort of issue is entirely unworthy of a 50 post war. Believe me, this will go on much longer then 50 posts unfortunately. - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:32 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Except this isn't just about you. You can do as you please licensing your own code, but you are importing code into an existing project with a well established license. If you want your code in such a project, you need to work with the other members to determine the license. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. Regards to all for what is still my preferred interface after many years. Thanks. M On Wed, Aug 6, 2008 at 6:36 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 7:29 PM, Luchezar Petkov [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel As a naught but a simple E user and occasional irc-lurker I have kept out of these sorts of discussions. This one however IMO is out of hand. Luchezar Petkov is 100% correct, please read his words above and take them into account. This sort of issue is entirely unworthy of a 50 post war. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Mark Dickie +57 314 204 6358 Email [EMAIL PROTECTED] Skype blaeberries - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 9:16 PM, Mark Dickie [EMAIL PROTECTED] wrote: As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
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. 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? 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, or he may not have bothered to check since everything else is BSD, he probably assumed it was BSD. 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
Re: [E-devel] E CVS: proto/eina turran
This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. See, It's not about BSD vs LGPL. It's just that we can't and we must not have our core libs dual licensed. I'm not saying that you or anyone else is not contributing or have to fork the tree or whatever. Just keep the consistency in the core. If the WHOLE core base cannot be LGPL'd then dont LGPL the new parts of it. This is ridiculous. I respect you all, your work, your desire to change the license but this is not the way to go. -- Luchezar P. Petkov http://luchko.net - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
So your argument is that you don't need to justify your choices because you're more active right now? On Wed, Aug 6, 2008 at 8:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:16 PM, Mark Dickie [EMAIL PROTECTED] wrote: As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Also, this is exactly my point about being disrespectful and hurting the community. You are devaluating the opinions of volunteers in the community because you get to spend your paid time on it. I still contribute multiple hours each week to the project either through reviewing patches, helping evaluate bug reports or working with my SoC student. Apparently, this is of no value to you and anyone in that role should just leave. If that were the case, anyone in the project for more than two years shouldn't be allowed to speak up, because we've all had to cut back our commit levels at some points. On Wed, Aug 6, 2008 at 8:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:16 PM, Mark Dickie [EMAIL PROTECTED] wrote: As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:26 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: So your argument is that you don't need to justify your choices because you're more active right now? Basically, and because your license says so. As for keeping core consistent, we CAN, if this is the only blocker, relicense ALL core components as LGPL and keep individual files as BSD, this is perfectly doable, just need to have the file header with the proper license. BSD files, while cannot be relicensed, can be casted (like in strongly typed language's cast) to LPGL. So whenever, during runtime, you link against LGPL, your resulting process is governed by LGPL. LGPL, on the other side, when linked to GPL, results in GPL and so the process and associated libraries. If you make this linkage static, or files inside the same process (can be defined as static linkage as well), you have to consider it all as the most demaing (ie: LGPL). That means we can license the PROJECT (ie: evas, ecore) under LGPL without asking anyone, we don't even have to mention that some files inside the project are BSD (since we're open source and bsd-raster says we don't have to acknoldge if it's open source, just if it's closed we need to inform the authors). What we must do is to keep BSD files with the proper header, if one wants to be smart and take files to compose a proprietary product, he can go through every file and check if it's possible or not, but the project overview or advice is to be LGPL. And before you continue, your license permits this, it's ok for you. If you find this is WRONG, then we're in the same boat, and we should go to LGPL to progressively fix this, replacing BSD bits with code evolution. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:42 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Also, this is exactly my point about being disrespectful and hurting the community. You are devaluating the opinions of volunteers in the community because you get to spend your paid time on it. I still contribute multiple hours each week to the project either through reviewing patches, helping evaluate bug reports or working with my SoC student. And you forgot to include ... keeping the flamewar hot, since that's what you've being doing these days. Apparently, this is of no value to you and anyone in that role should just leave. If that were the case, anyone in the project for more than two years shouldn't be allowed to speak up, because we've all had to cut back our commit levels at some points. this have some value, but I guess in a meritocracy those doing more, have more rights. And my point is not about talking much, but doing few. As Jorge said, people talked and talked about split data library. Nobody did a shit, it was he that did the work. It will be he and some other few to convert the libs to use it. If you, instead of talking, did the split and ported the libs, nothing of this would happen. Nobody has any right to force you to do such things, but you have no right to impose your opinion on the others too. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 8:45 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 10:26 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: So your argument is that you don't need to justify your choices because you're more active right now? Basically, and because your license says so. The license we're using does not say change the project-wide license decisions at the whim of newer committers. As for keeping core consistent, we CAN, if this is the only blocker, relicense ALL core components as LGPL and keep individual files as BSD, this is perfectly doable, just need to have the file header with the proper license. Yes, you can, though you can't use the names of components without permission as those belong to the authors No big deal renaming them though. BSD files, while cannot be relicensed, can be casted (like in strongly typed language's cast) to LPGL. So whenever, during runtime, you link against LGPL, your resulting process is governed by LGPL. LGPL, on the other side, when linked to GPL, results in GPL and so the process and associated libraries. If you make this linkage static, or files inside the same process (can be defined as static linkage as well), you have to consider it all as the most demaing (ie: LGPL). That means we can license the PROJECT (ie: evas, ecore) under LGPL without asking anyone, we don't even have to mention that some files inside the project are BSD (since we're open source and bsd-raster says we don't have to acknoldge if it's open source, just if it's closed we need to inform the authors). What we must do is to keep BSD files with the proper header, if one wants to be smart and take files to compose a proprietary product, he can go through every file and check if it's possible or not, but the project overview or advice is to be LGPL. And before you continue, your license permits this, it's ok for you. If you find this is WRONG, then we're in the same boat, and we should go to LGPL to progressively fix this, replacing BSD bits with code evolution. I know the license permits this, and I want it to permit it. Have fun, go fork a LGPL version of everything, couldn't care less. In fact I suggested that turran go do this to test his hypothesis that the choice of license is what is preventing community growth. I don't want the LGPL to be the single license for the official project because you now remove that freedom from anyone else choosing a different license in the future. Moving to the LGPL is a one-way change that we can't come back from without extraordinary effort. That would require getting permission from every author that contributed under the license, and it's already been shown that it's extremely difficult to track down past authors. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 8:55 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 10:42 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Also, this is exactly my point about being disrespectful and hurting the community. You are devaluating the opinions of volunteers in the community because you get to spend your paid time on it. I still contribute multiple hours each week to the project either through reviewing patches, helping evaluate bug reports or working with my SoC student. And you forgot to include ... keeping the flamewar hot, since that's what you've being doing these days. I guess so, although other people have spoken up and were ignored or given half-answers. I've received a number of private messages from community members that feel their voices are being ignored thanking me for not letting this license change slip in unchallenged. You think I like this ridiculous discussion? Not a bit, it's killing any motivation to do what little I can for E these days. I am only spending this much time because it's a very crucial and time sensitive issue. As I've learned in the past, if you don't speak up quickly on these things some people assume that means agreement. Apparently, this is of no value to you and anyone in that role should just leave. If that were the case, anyone in the project for more than two years shouldn't be allowed to speak up, because we've all had to cut back our commit levels at some points. this have some value, but I guess in a meritocracy those doing more, have more rights. And you get to choose the time scale and individual value of this meritocracy? How do I get that job? The way meritocracies work is that you gain respect within a community by contributing merit over a long period of time. You don't get granted authority by anyone, but people within the community weigh your opinion more heavily because of your long standing contributions. As I pointed out before, everyone that has worked on E for any significant amount of time has had a lull in their commit levels. You are not an exception to this rule either. And my point is not about talking much, but doing few. As Jorge said, people talked and talked about split data library. Nobody did a shit, it was he that did the work. It will be he and some other few to convert the libs to use it. Wrong again. I did this once already at least 6 years ago. At that time raster had decided that evas was not going to have any dependencies directly below it. As Jorge pointed out, his work has been sitting there for 2 years already. This was not about someone doing the work, but about the willingness to accept a data lib dependency on Evas. If you, instead of talking, did the split and ported the libs, nothing of this would happen. Nobody has any right to force you to do such things, but you have no right to impose your opinion on the others too. I already answered about the split. I am not the one trying to impose my opinion on the project. Did I come to the project and force us all to accept a new license? Have you refuted any of my reasons that I laid out for why this move doesn't make sense? There is a long email where I laid them out in detail. It got no real response from the proponents of this move, and the little response that I did get didn't counter any of my arguments. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 8:45 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 10:26 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: So your argument is that you don't need to justify your choices because you're more active right now? Basically, and because your license says so. The license we're using does not say change the project-wide license decisions at the whim of newer committers. As for keeping core consistent, we CAN, if this is the only blocker, relicense ALL core components as LGPL and keep individual files as BSD, this is perfectly doable, just need to have the file header with the proper license. Yes, you can, though you can't use the names of components without permission as those belong to the authors No big deal renaming them though. BSD files, while cannot be relicensed, can be casted (like in strongly typed language's cast) to LPGL. So whenever, during runtime, you link against LGPL, your resulting process is governed by LGPL. LGPL, on the other side, when linked to GPL, results in GPL and so the process and associated libraries. If you make this linkage static, or files inside the same process (can be defined as static linkage as well), you have to consider it all as the most demaing (ie: LGPL). That means we can license the PROJECT (ie: evas, ecore) under LGPL without asking anyone, we don't even have to mention that some files inside the project are BSD (since we're open source and bsd-raster says we don't have to acknoldge if it's open source, just if it's closed we need to inform the authors). What we must do is to keep BSD files with the proper header, if one wants to be smart and take files to compose a proprietary product, he can go through every file and check if it's possible or not, but the project overview or advice is to be LGPL. And before you continue, your license permits this, it's ok for you. If you find this is WRONG, then we're in the same boat, and we should go to LGPL to progressively fix this, replacing BSD bits with code evolution. I know the license permits this, and I want it to permit it. Have fun, go fork a LGPL version of everything, couldn't care less. In fact I suggested that turran go do this to test his hypothesis that the choice of license is what is preventing community growth. I don't want the LGPL to be the single license for the official project because you now remove that freedom from anyone else choosing a different license in the future. Moving to the LGPL is a one-way change that we can't come back from without extraordinary effort. That would require getting permission from every author that contributed under the license, and it's already been shown that it's extremely difficult to track down past authors. I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) dh - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 9:57 PM, Christopher Michael [EMAIL PROTECTED] wrote: I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) IANAL either, but the common understanding of the LGPL is that you are only allowed to relicense to GPL, and the GPL allows no relicensing. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 9:57 PM, Christopher Michael [EMAIL PROTECTED] wrote: I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) IANAL either, but the common understanding of the LGPL is that you are only allowed to relicense to GPL, and the GPL allows no relicensing. Thanks for clearing that up Nathan. That being the case, then count my vote in the don't change license column please :) dh - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 11:09 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:57 PM, Christopher Michael [EMAIL PROTECTED] wrote: I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) IANAL either, but the common understanding of the LGPL is that you are only allowed to relicense to GPL, and the GPL allows no relicensing. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Sort of ancillary to this discussion but as point of fact: GPL was designed to keep software free, away from people who would close it and then sell it. The Changing the license is hard with the GPL is very intentional and not entirely a negative point. It prevents someone from changing it 3 years later and making it not-free. If you read any of Richard Stallman the above comes through loud and clear everytime he talks, and like everybody else here, IANAL but that's common Stallman rhetoric. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:19 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: Sort of ancillary to this discussion but as point of fact: GPL was designed to keep software free, away from people who would close it and then sell it. The Changing the license is hard with the GPL is very intentional and not entirely a negative point. It prevents someone from changing it 3 years later and making it not-free. If you read any of Richard Stallman the above comes through loud and clear everytime he talks, and like everybody else here, IANAL but that's common Stallman rhetoric. No disagreement from me on any of those points. Those are the reasons some people prefer it. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel