Nicolas Pitre <nico@xxxxxxx> wrote: > On Fri, 31 Oct 2008, david@xxxxxxx wrote: > > On Fri, 31 Oct 2008, Nicolas Pitre wrote: > > > On Fri, 31 Oct 2008, Pierre Habouzit wrote: > > > > > > > Last but not least, I believe parts of git-core are currently easy to > > > > just take. For example, any code *I* wrote, I hereby give permission to > > > > relicense it in any of the following licenses: BSD-like, MIT-like, > > > > WTFPL. > > > > > > First........... is there really a need to re-license it? > > > If so then the choice of license is IMHO rather important. Some people want to be able to link the library into an application that they redistribute binaries of, but not sources to. Those folks have also volunteered to help write the library. If they put their code where their mouth is, then I think they should be able to use their code the way they want to. That said, I think the license choice that makes the most sense here is probably LGPL or GPL+gcc exception, like you note below. BSD and MIT are probably not serious contenders. > > at the very least you should go from GPLv2 to LGPLv2 for the library. > > Sure. Well, we cannot do a GPL->LGPL switch on code without author permission for that sort of re-licensing. That said, I think many authors of git.git code would be more comfortable with a GPL->LGPL change, where they wouldn't be OK with a GPL->BSD/MIT change. There may be some folks though who still wouldn't accept a GPL->LGPL move. > > > My favorite license for a library is the GPL with the gcc exception, ... > > > > > > For reference, here's the exception text: > > > > > > In addition to the permissions in the GNU General Public License, the > > > Free Software Foundation gives you unlimited permission to link the > > > compiled version of this file into combinations with other programs, > > > and to distribute those combinations without any restriction coming > > > from the use of this file. (The General Public License restrictions > > > do apply in other respects; for example, they cover modification of > > > the file, and distribution when not linked into a combine > > > executable.) > > > > <shrug>, I don't see why this is needed with the LGPL, but I'm not a lawyer. > > The LGPL also asks that proprietary applications provides necessary > object files so you can link it against an alternative implementation of > the LGPL library if you so wish. With dynamic libraries this is rather > moot but I think that's the main difference. I'm happy with either the LGPL or the GPL+exception above. If I read these correctly the GPL+exception allows one to distribute static executables without source or object files, so long as the library source wasn't modified. I'd almost prefer just using the standard LGPL then, static linking isn't very common anymore. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
