Re: [E-devel] Community Building - LoCos
Ive put together a couple ideas on a wiki entry. Its all concept stuff at the moment so the sourceforge mailing list doesnt work. I think it could be a great way to get small teams to collaborate on projects and then promote E and their own country. eg. Emulate - EFL based MAME emulator - proudly bought to you by AU-E team! Of course, this doesnt exist yet but its an example of a place that a team could show their colours. Personally, Id put a little 'Au-E' in all my theme about pages to show my patriotism. :) If anyone has any other ideas, Id like to hear them. Feel free to add/subtract to the wiki page. Toma http://wiki.enlightenment.org/index.php/E_Community_Teams On 03/08/2008, Toma [EMAIL PROTECTED] wrote: As mentioned on the Community Building thread, the idea for LoCos (Local Community) groups seems like a good way for people to feel involved and even get together for a beer or 3. It seems to work well for projects like Ubuntu so I thought Id start by showing the link on how their LoCos are built and maintained. http://wiki.ubuntu.com/LoCoTeamHowto It basically consists of a mailing list and an IRC channel. Now, an IRC channel might be a bit much for some, but a mailing list where people can ask their fellow LoCo members for help or just chat about things in regards to E or linux in general. I even made a little logo for an Australian team. :) Obviously up for debate, but its a little badge people can put in their apps/themes/blogs to show where theyre from and promote E and their own LoCo team. http://members.iinet.net.au/~haste/e17/Au-E.png So, if anyone thinks this is a good idea, or thinks the idea will fall flat on it arse, please comment. If it does seem like a bit of fun, Ill write a wiki on how to make an E LoCo and how to join one. Toma. - 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] Licensing suggestion [OFFTOPIC]
On Thu, 7 Aug 2008 13:41:15 +0800 Toma [EMAIL PROTECTED] wrote: As long as you retain this notice you can do whatever you want with this stuff. If you wish to use this in a commercial product, you must supply the AUTHOR or AUTHORS with 1 case of beer each. Which is probably a little closer to a GPL type of Beerware license. Er, I don't like beer, and gave up drinking alcohol along time ago. signature.asc Description: PGP signature - 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] Licensing suggestion [OFFTOPIC]
On 07/08/2008, David Seikel [EMAIL PROTECTED] wrote: On Thu, 7 Aug 2008 13:41:15 +0800 Toma [EMAIL PROTECTED] wrote: As long as you retain this notice you can do whatever you want with this stuff. If you wish to use this in a commercial product, you must supply the AUTHOR or AUTHORS with 1 case of beer each. Which is probably a little closer to a GPL type of Beerware license. Er, I don't like beer, and gave up drinking alcohol along time ago. You could change the clause of the license to be 'reasonably priced dinner or lunch' I guess? - 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] Licensing suggestion [OFFTOPIC]
As every reader is not in the AUTHOR or AUTHORS, could we make this licence give a pack of beer to everyone subscribed on list ? On 8/7/08, Toma [EMAIL PROTECTED] wrote: On 07/08/2008, David Seikel [EMAIL PROTECTED] wrote: On Thu, 7 Aug 2008 13:41:15 +0800 Toma [EMAIL PROTECTED] wrote: As long as you retain this notice you can do whatever you want with this stuff. If you wish to use this in a commercial product, you must supply the AUTHOR or AUTHORS with 1 case of beer each. Which is probably a little closer to a GPL type of Beerware license. Er, I don't like beer, and gave up drinking alcohol along time ago. You could change the clause of the license to be 'reasonably priced dinner or lunch' I guess? - 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 -- Charles de Noyelle [EMAIL PROTECTED] Il est probable que vous m'ayiez en double dans votre carnet d'adresse : [EMAIL PROTECTED] est la bonne. - 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] Licensing suggestion [OFFTOPIC] [JOKE]
On Thu, 7 Aug 2008 15:26:11 +0800 Toma [EMAIL PROTECTED] wrote: On 07/08/2008, David Seikel [EMAIL PROTECTED] wrote: On Thu, 7 Aug 2008 13:41:15 +0800 Toma [EMAIL PROTECTED] wrote: As long as you retain this notice you can do whatever you want with this stuff. If you wish to use this in a commercial product, you must supply the AUTHOR or AUTHORS with 1 case of beer each. Which is probably a little closer to a GPL type of Beerware license. Er, I don't like beer, and gave up drinking alcohol along time ago. You could change the clause of the license to be 'reasonably priced dinner or lunch' I guess? That works for. Let's start changing everything in CVS to that now. Though we should be careful with anything already infected with Large Gregarious Pubic Lice. (For the humour impaired, this is just a joke.) signature.asc Description: PGP signature - 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
[E-devel] licensing - end it.
ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. here's how it will go: 1. existing libs. the LGPL crowd - RESPECT the licenses already used. deal with it. the original authors chose the licenses. don't like it? go somewhere else. this is what pretty much every oss project will say - except for very small ones. 2. new libs. he who writes and licenses the lib initially makes the license call. if its LGPL or BSD - doesn't matter. but RESPECT their choice. just like they need to RESPECT the choices of existing libs and stop trying to change them. 3. new apps. same as libs - choose your license. BEWARE of GPL though. you CANNOT take the GPL code and put it into an LGPL lib - so if you see code going from app back to a lib sometime... think many times before GPL. licence the APP under LGPL - it'd be effectively the same. 4. linking TO LGPL libs is ok - we do it already anyway. 5. linking to GPL libs - be WARY. very. this makes your lib GPL and then any app using that lib GPL. beware of the chain of infection. if you want it a core lib used by everyone - chances are this is a very bad idea. i'm a little tired of the divisive political debating here. this is NOT a technical argument. it id not something u can win by benchmarking, numbers and proof. it's all emotions, speculation and politics. please take your politics elsewhere as this is the one thing that is really going to destroy this community if anything. i know i am personally -||- this far from saying fuck it - i'm out. if this is becoming a political playground i have better things to do that deal with it. now. make your choices. but enough of the politics. debate is healthy - technical debate. direction for features and code and technical stuff. we can always debate. its good. politics is nothing more than a way to divide and create little power encampments us and them. i have been very quiet - i was hoping people would sort their difference out quietly, but it seems i need to say something. i think i have been very reasonable here and have tried to accommodate BOTH sides. i see the arguments for LGPL etc. and i know why. i respect the desire for it - and when it is appropriate and sane/possible - if the author(s) want to use it, do so. by the same token respect the licenses there already. if 1 author for a project says no - i wont relicence or 1 authors alone simply never responds, it doesnt get relicenced. in fact the debate and effort spent relicencing is a big waste of time. so again - there are 2 valid sides to this. respect EACHOTHER. thanks. :) now... do we have productive stuff to do? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
[E-devel] [Patch] Tclock's tip and font classes.
Attached patch allows the tclock module's tip (that's a popup that appears when you hover the widget) understand font classes, so you can easily change the font using Fonts-Advanced dialog. -- King regards, Fedor Gusev. ? patch Index: tclock.edc === RCS file: /var/cvs/e/e_modules/tclock/tclock.edc,v retrieving revision 1.23 diff -u -r1.23 tclock.edc --- tclock.edc 26 Dec 2007 16:47:23 - 1.23 +++ tclock.edc 7 Aug 2008 13:46:11 - @@ -242,6 +242,7 @@ size: 12; min: 1 1; align: 0.5 0.5; + text_class: module_small; } } } - 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
[E-devel] Nightly build log for E17 on 2008-08-07 07:10:51 -0700
Build log for Enlightenment DR 0.17 on 2008-08-07 07:10:51 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, skel, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - 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] [Patch] Tclock's tip and font classes.
Hi Fedor, I'll ask *the* question everyone has on lips : is this code under LGPL or BSD ? More seriously, thanx for posting something about code ;-) On 8/7/08, Fedor Gusev [EMAIL PROTECTED] wrote: Attached patch allows the tclock module's tip (that's a popup that appears when you hover the widget) understand font classes, so you can easily change the font using Fonts-Advanced dialog. -- King regards, Fedor Gusev. - 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 -- Charles de Noyelle [EMAIL PROTECTED] Il est probable que vous m'ayiez en double dans votre carnet d'adresse : [EMAIL PROTECTED] est la bonne. - 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] licensing - end it.
- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. here's how it will go: 1. existing libs. the LGPL crowd - RESPECT the licenses already used. deal with it. the original authors chose the licenses. don't like it? go somewhere else. this is what pretty much every oss project will say - except for very small ones. 2. new libs. he who writes and licenses the lib initially makes the license call. if its LGPL or BSD - doesn't matter. but RESPECT their choice. just like they need to RESPECT the choices of existing libs and stop trying to change them. 3. new apps. same as libs - choose your license. BEWARE of GPL though. you CANNOT take the GPL code and put it into an LGPL lib - so if you see code going from app back to a lib sometime... think many times before GPL. licence the APP under LGPL - it'd be effectively the same. Thanks Raster!! finally a POW that respect the others :) Are you sure that we can (safetly) use LGPL for apps? From what I read on the gnu site LGPL is exaclty for libs, I didn't find nothing about using LGPL in apps. Thanks Dave 4. linking TO LGPL libs is ok - we do it already anyway. 5. linking to GPL libs - be WARY. very. this makes your lib GPL and then any app using that lib GPL. beware of the chain of infection. if you want it a core lib used by everyone - chances are this is a very bad idea. i'm a little tired of the divisive political debating here. this is NOT a technical argument. it id not something u can win by benchmarking, numbers and proof. it's all emotions, speculation and politics. please take your politics elsewhere as this is the one thing that is really going to destroy this community if anything. i know i am personally -||- this far from saying fuck it - i'm out. if this is becoming a political playground i have better things to do that deal with it. now. make your choices. but enough of the politics. debate is healthy - technical debate. direction for features and code and technical stuff. we can always debate. its good. politics is nothing more than a way to divide and create little power encampments us and them. i have been very quiet - i was hoping people would sort their difference out quietly, but it seems i need to say something. i think i have been very reasonable here and have tried to accommodate BOTH sides. i see the arguments for LGPL etc. and i know why. i respect the desire for it - and when it is appropriate and sane/possible - if the author(s) want to use it, do so. by the same token respect the licenses there already. if 1 author for a project says no - i wont relicence or 1 authors alone simply never responds, it doesnt get relicenced. in fact the debate and effort spent relicencing is a big waste of time. so again - there are 2 valid sides to this. respect EACHOTHER. thanks. :) now... do we have productive stuff to do? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] licensing - end it.
On Thu, 7 Aug 2008 16:15:37 +0200 (CEST) Dave Andreoli [EMAIL PROTECTED] babbled: Thanks Raster!! finally a POW that respect the others :) Are you sure that we can (safetly) use LGPL for apps? From what I read on the gnu site LGPL is exaclty for libs, I didn't find nothing about using LGPL in apps. nothing stops LGPL being used for an app. the FSF can't go dictate this to you - unless of course they wish to be guilty of the closedness they are so adamant and picky about fighting. LGPL CAN be applied to an app. any time. it just isnt that meaningful when applied to an app. it effectively is GPL - BUT allows re-use/movement of the code from the GPL app into the LGPL lib without relicensing, as GPL is more restrictive than LGPL. :) now... everyone - back to something PRODUCTIVE! -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] licensing - end it.
Carsten Haitzler (The Rasterman) wrote: On Thu, 7 Aug 2008 16:15:37 +0200 (CEST) Dave Andreoli [EMAIL PROTECTED] babbled: Thanks Raster!! finally a POW that respect the others :) Are you sure that we can (safetly) use LGPL for apps? From what I read on the gnu site LGPL is exaclty for libs, I didn't find nothing about using LGPL in apps. nothing stops LGPL being used for an app. the FSF can't go dictate this to you - unless of course they wish to be guilty of the closedness they are so adamant and picky about fighting. LGPL CAN be applied to an app. any time. it just isnt that meaningful when applied to an app. it effectively is GPL - BUT allows re-use/movement of the code from the GPL app into the LGPL lib without relicensing, as GPL is more restrictive than LGPL. :) now... everyone - back to something PRODUCTIVE! Can you move code from an LGPL/GPL app into a BSD library with the permission of the author of that code and just that specific 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] licensing - end it.
On Thu, 07 Aug 2008 09:57:00 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) wrote: On Thu, 7 Aug 2008 16:15:37 +0200 (CEST) Dave Andreoli [EMAIL PROTECTED] babbled: Thanks Raster!! finally a POW that respect the others :) Are you sure that we can (safetly) use LGPL for apps? From what I read on the gnu site LGPL is exaclty for libs, I didn't find nothing about using LGPL in apps. nothing stops LGPL being used for an app. the FSF can't go dictate this to you - unless of course they wish to be guilty of the closedness they are so adamant and picky about fighting. LGPL CAN be applied to an app. any time. it just isnt that meaningful when applied to an app. it effectively is GPL - BUT allows re-use/movement of the code from the GPL app into the LGPL lib without relicensing, as GPL is more restrictive than LGPL. :) now... everyone - back to something PRODUCTIVE! Can you move code from an LGPL/GPL app into a BSD library with the permission of the author of that code and just that specific code? yes. the copyrightholder of that code is ALWAYS allowed to relicence ANY WAY THEY LIKE. existing released code comes under any existing licenses. thats is how dual-licensing works. the copyright holder offers under 2 licenses - you pick. one may allow closed development (eg qt) but in return for getting it under that license, you must pay a fee. a copyright holder can take their own code and release exactly that code or a modified/derived copy of it under any license they like as they own that. of course the existing release under existing license doesn't become invalid. example. assume i owned 100% of the code of evas. tomorrow i can make a new evas release that is a closed commercial license - even if evas was GPL. why? i own it. i can make any future development closed and commercial. *IF* i want to. of course the EXISTING release is always available and if you want an open evas - you'd need to fork it and continue dev from the last open licenced version. of course i'll never do that. but it's an example. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] licensing - end it.
Carsten Haitzler (The Rasterman) wrote: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. here's how it will go: 1. existing libs. the LGPL crowd - RESPECT the licenses already used. deal with it. the original authors chose the licenses. don't like it? go somewhere else. this is what pretty much every oss project will say - except for very small ones. 2. new libs. he who writes and licenses the lib initially makes the license call. if its LGPL or BSD - doesn't matter. but RESPECT their choice. just like they need to RESPECT the choices of existing libs and stop trying to change them. 3. new apps. same as libs - choose your license. BEWARE of GPL though. you CANNOT take the GPL code and put it into an LGPL lib - so if you see code going from app back to a lib sometime... think many times before GPL. licence the APP under LGPL - it'd be effectively the same. 4. linking TO LGPL libs is ok - we do it already anyway. 5. linking to GPL libs - be WARY. very. this makes your lib GPL and then any app using that lib GPL. beware of the chain of infection. if you want it a core lib used by everyone - chances are this is a very bad idea. i'm a little tired of the divisive political debating here. this is NOT a technical argument. it id not something u can win by benchmarking, numbers and proof. it's all emotions, speculation and politics. please take your politics elsewhere as this is the one thing that is really going to destroy this community if anything. i know i am personally -||- this far from saying fuck it - i'm out. if this is becoming a political playground i have better things to do that deal with it. now. make your choices. but enough of the politics. debate is healthy - technical debate. direction for features and code and technical stuff. we can always debate. its good. politics is nothing more than a way to divide and create little power encampments us and them. i have been very quiet - i was hoping people would sort their difference out quietly, but it seems i need to say something. i think i have been very reasonable here and have tried to accommodate BOTH sides. i see the arguments for LGPL etc. and i know why. i respect the desire for it - and when it is appropriate and sane/possible - if the author(s) want to use it, do so. by the same token respect the licenses there already. if 1 author for a project says no - i wont relicence or 1 authors alone simply never responds, it doesnt get relicenced. in fact the debate and effort spent relicencing is a big waste of time. so again - there are 2 valid sides to this. respect EACHOTHER. thanks. :) now... do we have productive stuff to do? Agreed !! 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: tclock mekius
Enlightenment CVS wrote: Enlightenment CVS committal Author : mekius Project : e_modules Module : tclock Dir : e_modules/tclock Modified Files: tclock.edc Log Message: Patch from ptomaine, my awesome GSOC student :), to make the popup use font classes. Thanks Nick :) I assume you tested it first ?? ;) 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: tclock mekius
Christopher Michael wrote: Enlightenment CVS wrote: Enlightenment CVS committal Author : mekius Project : e_modules Module : tclock Dir : e_modules/tclock Modified Files: tclock.edc Log Message: Patch from ptomaine, my awesome GSOC student :), to make the popup use font classes. Thanks Nick :) I assume you tested it first ?? ;) Of course :D 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 - 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: tclock mekius
Nick Hughart wrote: Christopher Michael wrote: Enlightenment CVS wrote: Enlightenment CVS committal Author : mekius Project : e_modules Module : tclock Dir : e_modules/tclock Modified Files: tclock.edc Log Message: Patch from ptomaine, my awesome GSOC student :), to make the popup use font classes. Thanks Nick :) I assume you tested it first ?? ;) Of course :D dh Thanks :) I hope this does not mean that I have to change the license now :P 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: tclock mekius
Christopher Michael wrote: Nick Hughart wrote: Christopher Michael wrote: Enlightenment CVS wrote: Enlightenment CVS committal Author : mekius Project : e_modules Module : tclock Dir : e_modules/tclock Modified Files: tclock.edc Log Message: Patch from ptomaine, my awesome GSOC student :), to make the popup use font classes. Thanks Nick :) I assume you tested it first ?? ;) Of course :D dh Thanks :) I hope this does not mean that I have to change the license now :P Oh don't start now :P 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] licensing - end it.
Carsten wrote: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. That's no doubt true as a rule on any given project, but statistics show that gpl/lgpl code and developers outnumber bsd ones by orders of magnitude. Your feelings on it are a bit subjective, and so might those of others who prefer some other license, but that's a fact that should be recognized, not a squabble. here's how it will go: 1. existing libs. the LGPL crowd - RESPECT the licenses already used. deal with it. the original authors chose the licenses. don't like it? go somewhere else. this is what pretty much every oss project will say - except for very small ones. 2. new libs. he who writes and licenses the lib initially makes the license call. if its LGPL or BSD - doesn't matter. but RESPECT their choice. just like they need to RESPECT the choices of existing libs and stop trying to change them. No one proposing either licensing their work as lgpl, or even just asking for other's views on a possible change, has disrespected any author -- not as far as I can see. 3. new apps. same as libs - choose your license. BEWARE of GPL though. you CANNOT take the GPL code and put it into an LGPL lib - so if you see code going from app back to a lib sometime... think many times before GPL. licence the APP under LGPL - it'd be effectively the same. 4. linking TO LGPL libs is ok - we do it already anyway. 5. linking to GPL libs - be WARY. very. this makes your lib GPL and then any app using that lib GPL. beware of the chain of infection. if you want it a core lib used by everyone - chances are this is a very bad idea. i'm a little tired of the divisive political debating here. this is NOT a technical argument. it id not something u can win by benchmarking, numbers and proof. it's all emotions, speculation and politics. please take your politics elsewhere as this is the one thing that is really going to destroy this community if anything. i know i am personally -||- this far from saying fuck it - i'm out. if this is becoming a political playground i have better things to do that deal with it. now. make your choices. but enough of the politics. debate is healthy - technical debate. direction for features and code and technical stuff. we can always debate. its good. politics is nothing more than a way to divide and create little power encampments us and them. i have been very quiet - i was hoping people would sort their difference out quietly, but it seems i need to say something. i think i have been very reasonable here and have tried to accommodate BOTH sides. i see the arguments for LGPL etc. and i know why. i respect the desire for it - and when it is appropriate and sane/possible - if the author(s) want to use it, do so. by the same token respect the licenses there already. if 1 author for a project says no - i wont relicence or 1 authors alone simply never responds, it doesnt get relicenced. in fact the debate and effort spent relicencing is a big waste of Again, no one tried to force or impose changing any existing license on a project agaisnt anyone's wishes... some did ask, but that's neither disrespect nor intolerance. But also note that bsd does explicitly champion the right to relicense the code.. that's part of the very thing many have defended here as their reason for choosing such a license. time. so again - there are 2 valid sides to this. respect EACHOTHER. Indeed, well said. thanks. :) now... do we have productive stuff to do? Argue some more, call each other names.. then go out for a beer or reasonably priced meal? :) Get expert advice on your inheritance. Click here for more information. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mKSlbQcijuE1TAn7oNNAdEmnu0QMIdoRYMEPtpWYi7t4Xbm/ - 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] licensing - end it.
Jose Gonzalez wrote: Carsten wrote: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. That's no doubt true as a rule on any given project, but statistics show that gpl/lgpl code and developers outnumber bsd ones by orders of magnitude. Your feelings on it are a bit subjective, and so might those of others who prefer some other license, but that's a fact that should be recognized, not a squabble. Anyone who paid attention in class would know that correlation != causation. Quit making assumptions. here's how it will go: 1. existing libs. the LGPL crowd - RESPECT the licenses already used. deal with it. the original authors chose the licenses. don't like it? go somewhere else. this is what pretty much every oss project will say - except for very small ones. 2. new libs. he who writes and licenses the lib initially makes the license call. if its LGPL or BSD - doesn't matter. but RESPECT their choice. just like they need to RESPECT the choices of existing libs and stop trying to change them. No one proposing either licensing their work as lgpl, or even just asking for other's views on a possible change, has disrespected any author -- not as far as I can see. 3. new apps. same as libs - choose your license. BEWARE of GPL though. you CANNOT take the GPL code and put it into an LGPL lib - so if you see code going from app back to a lib sometime... think many times before GPL. licence the APP under LGPL - it'd be effectively the same. 4. linking TO LGPL libs is ok - we do it already anyway. 5. linking to GPL libs - be WARY. very. this makes your lib GPL and then any app using that lib GPL. beware of the chain of infection. if you want it a core lib used by everyone - chances are this is a very bad idea. i'm a little tired of the divisive political debating here. this is NOT a technical argument. it id not something u can win by benchmarking, numbers and proof. it's all emotions, speculation and politics. please take your politics elsewhere as this is the one thing that is really going to destroy this community if anything. i know i am personally -||- this far from saying fuck it - i'm out. if this is becoming a political playground i have better things to do that deal with it. now. make your choices. but enough of the politics. debate is healthy - technical debate. direction for features and code and technical stuff. we can always debate. its good. politics is nothing more than a way to divide and create little power encampments us and them. i have been very quiet - i was hoping people would sort their difference out quietly, but it seems i need to say something. i think i have been very reasonable here and have tried to accommodate BOTH sides. i see the arguments for LGPL etc. and i know why. i respect the desire for it - and when it is appropriate and sane/possible - if the author(s) want to use it, do so. by the same token respect the licenses there already. if 1 author for a project says no - i wont relicence or 1 authors alone simply never responds, it doesnt get relicenced. in fact the debate and effort spent relicencing is a big waste of Again, no one tried to force or impose changing any existing license on a project agaisnt anyone's wishes... some did ask, but that's neither disrespect nor intolerance. But also note that bsd does explicitly champion the right to relicense the code.. that's part of the very thing many have defended here as their reason for choosing such a license. time. so again - there are 2 valid sides to this. respect EACHOTHER. Indeed, well said. thanks. :) now... do we have productive stuff to do? Argue some more, call each other names.. then go out for a beer or reasonably priced meal? :) Define reasonably priced? I'll settle for nothing less then $100 a seat :P Get expert advice on your inheritance. Click here for more information. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mKSlbQcijuE1TAn7oNNAdEmnu0QMIdoRYMEPtpWYi7t4Xbm/ - 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] licensing - end it.
Nick wrote: Jose Gonzalez wrote: Carsten wrote: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. That's no doubt true as a rule on any given project, but statistics show that gpl/lgpl code and developers outnumber bsd ones by orders of magnitude. Your feelings on it are a bit subjective, and so might those of others who prefer some other license, but that's a fact that should be recognized, not a squabble. Anyone who paid attention in class would know that correlation != causation. Quit making assumptions. No one is implying proof of direct causation. But it's quite foolish to ignore or brush-off correlations which have orders of magnitude significance. Make the right decisions about your inheritance. Click here for more information. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mKSlJPRv1xuLvl9r5Kge1MMeZ5ey1CKcqRcyxHAGs9w5FjJ/ - 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] licensing - end it.
Jose Gonzalez wrote: Nick wrote: Jose Gonzalez wrote: Carsten wrote: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. That's no doubt true as a rule on any given project, but statistics show that gpl/lgpl code and developers outnumber bsd ones by orders of magnitude. Your feelings on it are a bit subjective, and so might those of others who prefer some other license, but that's a fact that should be recognized, not a squabble. Anyone who paid attention in class would know that correlation != causation. Quit making assumptions. No one is implying proof of direct causation. But it's quite foolish to ignore or brush-off correlations which have orders of magnitude significance. Correlation without causation has no significance. It's just a freak accident until it's proven there is causation. Make the right decisions about your inheritance. Click here for more information. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mKSlJPRv1xuLvl9r5Kge1MMeZ5ey1CKcqRcyxHAGs9w5FjJ/ - 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] licensing - end it.
Nick Hughart wrote: Jose Gonzalez wrote: Nick wrote: Jose Gonzalez wrote: Carsten wrote: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. That's no doubt true as a rule on any given project, but statistics show that gpl/lgpl code and developers outnumber bsd ones by orders of magnitude. Your feelings on it are a bit subjective, and so might those of others who prefer some other license, but that's a fact that should be recognized, not a squabble. Anyone who paid attention in class would know that correlation != causation. Quit making assumptions. No one is implying proof of direct causation. But it's quite foolish to ignore or brush-off correlations which have orders of magnitude significance. Correlation without causation has no significance. It's just a freak accident until it's proven there is causation. I think you'll find that statement rather vacuous.. but feel free to disagree, I have no inclination to continue pursuing this here with you. Click to see huge collection of discounted designer watches. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mdA28Es2Y4PNzIffrSNnkL3gYPfMWA1iY6tCMi87AjxgoWL/ - 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] RFC: embryo release in 2 weeks
Am Samstag 02 August 2008 02:52:08 schrieb Carsten Haitzler: On Sat, 2 Aug 2008 08:25:17 +0800 Toma [EMAIL PROTECTED] babbled: seems there's a few votes for keep of embryo. i'm going to just monitor the sentiment here - i'm agnostic really - though edje needs a LOT better scripting support. yes JS might be an option - python imho is just away too big and heavy. existing efl bindings are not really useful as edje will have to wrap and hide most things - ie you set up a timer - edje needs to know so it can delete the timer on edje object deletion. just an example. so it's pretty much a level playing field based on: 1. efficiency of the language - the leaner/faster, the better 2. actual language ease of use/documentation/facilities. etc. 3. aptness of the language engine to embedding as a slave to a library for doing code logic (ie be able to function fully sandboxed without any features/calls and all calls are explicitly exported from edje). lua right now seems to be probably the candidate i've seen. embryo is a close second (used to be better than lua). As much as I'd like to see Python being there, I have to agree with it being to heavy for that. Lua would be ok. -- :M: - 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] licensing - end it.
On Thu, Aug 7, 2008 at 11:15 AM, Dave Andreoli [EMAIL PROTECTED] wrote: - Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. here's how it will go: 1. existing libs. the LGPL crowd - RESPECT the licenses already used. deal with it. the original authors chose the licenses. don't like it? go somewhere else. this is what pretty much every oss project will say - except for very small ones. 2. new libs. he who writes and licenses the lib initially makes the license call. if its LGPL or BSD - doesn't matter. but RESPECT their choice. just like they need to RESPECT the choices of existing libs and stop trying to change them. 3. new apps. same as libs - choose your license. BEWARE of GPL though. you CANNOT take the GPL code and put it into an LGPL lib - so if you see code going from app back to a lib sometime... think many times before GPL. licence the APP under LGPL - it'd be effectively the same. Thanks Raster!! finally a POW that respect the others :) Are you sure that we can (safetly) use LGPL for apps? From what I read on the gnu site LGPL is exaclty for libs, I didn't find nothing about using LGPL in apps. I know raster already replied, but for sake of completeness, L in LGPL means LESSER, not LIBRARY, thus it's a LESSER GPL. -- 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] licensing - end it.
An we've already heard your arguments, case closed now get to work! We've already lost time, members and devs due to this ridiculous debate. On Thu, Aug 7, 2008 at 9:22 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Carsten wrote: ok. enough of the squabbling. e is not a political football. license is not a reason one way or another for success or failure if licenses are oss anyway. we're squabbling about strawberry vs chocolate. That's no doubt true as a rule on any given project, but statistics show that gpl/lgpl code and developers outnumber bsd ones by orders of magnitude. Your feelings on it are a bit subjective, and so might those of others who prefer some other license, but that's a fact that should be recognized, not a squabble. here's how it will go: 1. existing libs. the LGPL crowd - RESPECT the licenses already used. deal with it. the original authors chose the licenses. don't like it? go somewhere else. this is what pretty much every oss project will say - except for very small ones. 2. new libs. he who writes and licenses the lib initially makes the license call. if its LGPL or BSD - doesn't matter. but RESPECT their choice. just like they need to RESPECT the choices of existing libs and stop trying to change them. No one proposing either licensing their work as lgpl, or even just asking for other's views on a possible change, has disrespected any author -- not as far as I can see. 3. new apps. same as libs - choose your license. BEWARE of GPL though. you CANNOT take the GPL code and put it into an LGPL lib - so if you see code going from app back to a lib sometime... think many times before GPL. licence the APP under LGPL - it'd be effectively the same. 4. linking TO LGPL libs is ok - we do it already anyway. 5. linking to GPL libs - be WARY. very. this makes your lib GPL and then any app using that lib GPL. beware of the chain of infection. if you want it a core lib used by everyone - chances are this is a very bad idea. i'm a little tired of the divisive political debating here. this is NOT a technical argument. it id not something u can win by benchmarking, numbers and proof. it's all emotions, speculation and politics. please take your politics elsewhere as this is the one thing that is really going to destroy this community if anything. i know i am personally -||- this far from saying fuck it - i'm out. if this is becoming a political playground i have better things to do that deal with it. now. make your choices. but enough of the politics. debate is healthy - technical debate. direction for features and code and technical stuff. we can always debate. its good. politics is nothing more than a way to divide and create little power encampments us and them. i have been very quiet - i was hoping people would sort their difference out quietly, but it seems i need to say something. i think i have been very reasonable here and have tried to accommodate BOTH sides. i see the arguments for LGPL etc. and i know why. i respect the desire for it - and when it is appropriate and sane/possible - if the author(s) want to use it, do so. by the same token respect the licenses there already. if 1 author for a project says no - i wont relicence or 1 authors alone simply never responds, it doesnt get relicenced. in fact the debate and effort spent relicencing is a big waste of Again, no one tried to force or impose changing any existing license on a project agaisnt anyone's wishes... some did ask, but that's neither disrespect nor intolerance. But also note that bsd does explicitly champion the right to relicense the code.. that's part of the very thing many have defended here as their reason for choosing such a license. time. so again - there are 2 valid sides to this. respect EACHOTHER. Indeed, well said. thanks. :) now... do we have productive stuff to do? Argue some more, call each other names.. then go out for a beer or reasonably priced meal? :) Get expert advice on your inheritance. Click here for more information. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mKSlbQcijuE1TAn7oNNAdEmnu0QMIdoRYMEPtpWYi7t4Xbm/ - 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
