Evil fedora package & license issue
Vegard Øye
vegard_oye at hotmail.com
Tue Jul 31 15:14:18 CEST 2012
On 2012-07-30 15:13 +0200, Frank Fischer wrote:
> Evil now contains some code snippets stolen from other sources,
> usually from GNU Emacs itself (I know this because I've been the
> thief ;)). These files are usually distributed under GPLv3 whereas
> Evil still has GPLv2. For correctness we should therefore upgrade
> the licensing to GPLv3, too.
The following article from 2007 explains how and why one should
upgrade from GPLv2 to GPLv3:
http://gplv3.fsf.org/rms-why.html
As I understand it, using GPLv3 code in a program means that the whole
code base must be upgraded to GPLv3:
"When we say that GPLv2 and GPLv3 are incompatible, it means there
is no legal way to combine code under GPLv2 with code under GPLv3
in a single program. This is because both GPLv2 and GPLv3 are
copyleft licenses: each of them says, 'If you include code under
this license in a larger program, the larger program must be under
this license too.' There is no way to make them compatible. We
could add a GPLv2-compatibility clause to GPLv3, but it wouldn't
do the job, because GPLv2 would need a similar clause."
However, this shouldn't pose any problems for packaging:
"Fortunately, license incompatibility only matters when you want
to link, merge or combine code from two different programs into a
single program. There is no problem in having GPLv3-covered and
GPLv2-covered programs side by side in an operating system. For
instance, the TeX license and the Apache license are incompatible
with GPLv2, but that doesn't stop us from running TeX and Apache
in the same system with Linux, Bash and GCC. This is because they
are all separate programs. Likewise, if Bash and GCC move to
GPLv3, while Linux remains under GPLv2, there is no conflict."
> Is there any problem with this (I ask all contributors)? (Otherwise
> I'll simple change the "2" to a "3" in the license comments).
I think we should upgrade to GPLv3 right away.
--
Vegard
More information about the implementations-list
mailing list