Nathan Ingersoll wrote: > On Wed, Aug 6, 2008 at 8:45 PM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: >> On Wed, Aug 6, 2008 at 10:26 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: >>> So your argument is that you don't need to justify your choices >>> because you're more active right now? >> Basically, and because your license says so. > > The license we're using does not say "change the project-wide license > decisions at the whim of newer committers." > >> As for keeping core consistent, we CAN, if this is the only blocker, >> relicense ALL core components as LGPL and keep individual files as >> BSD, this is perfectly doable, just need to have the file header with >> the proper license. > > Yes, you can, though you can't use the names of components without > permission as those belong to the authors No big deal renaming them > though. > >> BSD files, while cannot be relicensed, can be "casted" (like in >> strongly typed language's cast) to LPGL. So whenever, during runtime, >> you link against LGPL, your resulting process is governed by LGPL. >> LGPL, on the other side, when linked to GPL, results in GPL and so the >> process and associated libraries. If you make this linkage static, or >> files inside the same process (can be defined as static linkage as >> well), you have to consider it all as the most demaing (ie: LGPL). >> >> That means we can license the PROJECT (ie: evas, ecore) under LGPL >> without asking anyone, we don't even have to mention that some files >> inside the project are BSD (since we're open source and bsd-raster >> says we don't have to acknoldge if it's open source, just if it's >> closed we need to inform the authors). What we must do is to keep BSD >> files with the proper header, if one wants to be smart and take files >> to compose a proprietary product, he can go through every file and >> check if it's possible or not, but the project overview or advice is >> to be LGPL. >> >> And before you continue, your license permits this, it's ok for you. >> If you find this is WRONG, then we're in the same boat, and we should >> go to LGPL to progressively "fix" this, replacing BSD bits with code >> evolution. > > I know the license permits this, and I want it to permit it. Have fun, > go fork a LGPL version of everything, couldn't care less. In fact I > suggested that turran go do this to test his hypothesis that the > choice of license is what is preventing community growth. I don't want > the LGPL to be the single license for the official project because you > now remove that freedom from anyone else choosing a different license > in the future. > > Moving to the LGPL is a one-way change that we can't come back from > without extraordinary effort. That would require getting permission > from every author that contributed under the license, and it's already > been shown that it's extremely difficult to track down past authors. > I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the "Not Changing" crowd :)
dh ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
