linux-kernel - Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <orwsxwfvzj.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Fri, 22 Jun 2007 01:34:24 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Bron Gondwana <brong@...tmail.fm>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

On Jun 21, 2007, Bron Gondwana <brong@...tmail.fm> wrote:

> None of this "Projects" nonsense.

The reason I mentioned projects was because each project has its
policies, around the interests of its own community.  Each project can
thus make a decision about its own policies, just like Linux has made
its own decisions.

It was not my intent to suggest that developers in certain projects
(communities, groups, however you want to name that) should grant
permissions for cooperation with other specific projects, even though
this is certainly something that can be done under copyright law.

So don't read too much into "project", think of it as "policy in a
particular community of developers", and note that the terms I
suggested didn't make any reference whatsoever to projects, but rather
to licenses (part of the policy of each project).

> Suddenly using other GPLv2 code becomes fraught with "which path did
> I obtain this licence down" games

I don't see how this could possibly be come up as a consequence of my
suggestion.  In fact, it is my understanding that the path is not
relevant, what matters is the terms under which the copyright holders
are willing to license their code.  That someone might be able to
enforce stricter terms upon a combined work is just a consequence of
the "most restrictive license" rule, not of the path the code
followed.  But IANAL.

> You're not going to make a happy, happy merging code sharing world
> by fragmenting the licence landscape even more.

I take it that removing barriers to cooperation in GPLv3 by default is
undesirable.  Well, then, what can I say?  I tried.  :-(

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@...dhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@...d.ic.unicamp.br, gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/