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=100&url=/ >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
