On Tue, Apr 24, 2012 at 00:51, David Seikel <onef...@gmail.com> wrote: > On Mon, 23 Apr 2012 22:42:22 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > >> On Mon, 23 Apr 2012 15:05:09 +0200 thomasg <tho...@gstaedtner.net> >> said: >> >> > On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler >> > <ras...@rasterman.com> wrote: >> > > On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri >> > > <vincent.to...@gmail.com> said: >> > > >> > > actually forget lz4hc... lgpl3. >> > > >> > >> hey >> > >> >> > >> just found that while reading the gnutls ML : >> > >> >> > >> http://code.google.com/p/lz4/ >> > >> >> > >> it seems that it allows the same ratio for compression than zlib >> > >> but seems to be by far faster than zlib >> > >> >> > >> the memory consumption should be tested too. >> > >> >> > >> What do you think ? >> > >> >> > >> Vincent >> > >> >> > >> ------------------------------------------------------------------------------ >> > >> For Developers, A Lot Can Happen In A Second. >> > >> Boundary is the first to Know...and Tell You. >> > >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> > >> http://p.sf.net/sfu/Boundary-d2dvs2 >> > >> _______________________________________________ >> > >> enlightenment-devel mailing list >> > >> enlightenment-devel@lists.sourceforge.net >> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> > > >> > > >> > > -- >> > > ------------- Codito, ergo sum - "I code, therefore I am" >> > > -------------- The Rasterman (Carsten Haitzler) >> > > ras...@rasterman.com >> > > >> > > >> > > ------------------------------------------------------------------------------ >> > > For Developers, A Lot Can Happen In A Second. >> > > Boundary is the first to Know...and Tell You. >> > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> > > http://p.sf.net/sfu/Boundary-d2dvs2 >> > > _______________________________________________ >> > > enlightenment-devel mailing list >> > > enlightenment-devel@lists.sourceforge.net >> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> > I don't see any problem using an LGPLv3 library. Are there really >> > any changes necessary to make use of it in eet? Also, would it have >> > to be distributed in a way where LGPL parts would actually be >> > packed into an Eet binary or Eet source code? >> >> there i a problem because we'd have to compile it into eet - which >> would make eet lgpl3. gpl and lgpl3 are also highly propblematice in >> terms of acceptance. they are controversial at best. >> >> > Although I of course can understand that it would not be possible to >> > use Eet in an environment where no LGPL library could be accepted, >> > wherever or whyever that would be. >> >> no, it's the gpl/lgpl3 (as opposed to 2). > > I'd be one of those not accepting of GPL 3, or it's variations. Google > does not accept any GPL variants in Android officially, even though they > rely on a few GPL parts for the base OS. Including the Linux kernel.
Google does this in Android because Android is not an actual open source project - it's a google project which might or might not be released as open source at any point after a release. The GPL does not allow for software to be released as closed source, that's why google won't allow it in their distribution unless necessary. > For what it's worth, I think I found a GPL3 bit buried deep in the > ewebkit dependencies, but I kinda gave up for now after I had gotten > several levels deep in dependency hell. I think the plan with ewebkit > is to strip out some more dependencies to replace them with EFL bits? > That would help, but right now it's a bitch to compile on Ubuntu > 10.04. I'll try again later, when there is less dependencies, or > after I upgrade to Ubuntu 12.04 later this year. Just because a GPL application is a dependency at some point does not mean it will make the project GPL. You have to explicitly link to it, unless the application itself would include GPL sourcecode unknowingly which would technically make your application GPL. Then again, that's a very rare case and it is specific to the GPL, not the LGPL. > That's the danger with GPL 3 on huge projects. The main project might > be BSD or something, but buried deep is a GPL 3 component of a sub > component of a dependency that no one noticed. Likely coz it was GPL 2 > when it went in. Then the entire thing is contaminated. FSF has been > painting GPL 2 in a bad light, and swapping licenses on old versions of > GNU stuff with out telling people. I think that's despicable. Yes, there is a danger with the GPLv3 on huge projects. On huge closed source projects that is. You cannot stuff GPLv3 software in it and not expect the user to get the sourcecode and change this parts. Thats what the GPLv3 is about, and there are valid reasons for it. If you want to use a GPLv3 software in your closed source project, you of course have to be careful, because the author of this software decided that he did not want you to use it there without making available your changes. The GPLv3 exists for a big number of very specific occasions where big companies made big money with heavy use of GPLv2 software and decided their users and developers freedoms, which the GPL explicitly grants, were not valid. > FSF may be good for their Four Freedoms, but they take away an > important freedom with everything they touch. I have seen GPL > stifling innovation in large projects. And this is precisely why, we > may not use this new compression thing just coz we want EET to be BSD, > and not be forced to make it GPL. Yes, GPL might be trouble if your goal is never to honor the license. Deal with it. Anyway, I can fully understand and appreciate any authors decision to keep his license, i.e. BSD, without having to make it GPL by pulling in a minor GPL component. However, what we're talking about here is not GPL but LGPL and I was under the impression that linking to e.g. liblzma was enough, so no code from it would have to go actually into Eet. And that this is not a problem is pretty clear, because Eet already links to, and heavily uses, an LGPL library: Eina. As was pointed out earlier, the LZMA algorithm and probably a large part of liblzma is even public domain, so it could easily be integrated directly without any license concerns, so I think we can safely end the license debate before the first people get mad :) > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
