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-next>] [day] [month] [year] [list]
Message-ID: <orlkedpryc.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Thu, 21 Jun 2007 06:39:07 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	linux-kernel@...r.kernel.org
Subject: how about mutual compatibility between Linux's GPLv2 and GPLv3?

Here's an idea that just occurred to me, after all the discussions
about motivations, tit-for-tat, authors' wishes and all.

If GPLv3 were to have a clause that permitted combination/linking with
code under GPLv2, this wouldn't be enough for GPLv3 projects to use
Linux code, and it wouldn't be enough for Linux code to use GPLv3
projects.  That's because GPLv2 would still demand all code to be
licensed under GPLv2, and GPLv3 wouldn't permit this.

However, if GPLv3 had a permission to combine/link with code under
GPLv2, *and* Linux (and any other projects interested in mutual
compatibility) introduced an additional permission to combine/link
with code under GPLv3 (or even GPLv3+, constrained by some condition
if you will), then:

- the kernel Linux could use code from GPLv3 projects

- GPLv3 projects could use code from Linux

- each copyright holder would still get to enforce the terms s/he
  chose for his/her own code

Does this sound like something that would make sense for your
community, so as to maintain/increase cooperation between authors who
love GPLv2 and those who love defense for freedom, while respecting
each author's not-always-compatible wishes?

In other words, does it even make sense for the FSF to consider
introducing such a provision in GPLv3, that AFAICT, by itself, would
have no effect whatsoever, since an additional permission would be
needed for the GPLv2 side?


If you were to permit compatibility with GPLv3+ (rather than GPLv3),
would you constrain it?  Would something like:

  as long as the later version grants each licensee the same
  permissions as GPLv2, except for constraining permissions that would
  enable one licensee to deny other licensees the exercise of the
  permissions granted by both licenses

do, subject to translation to proper legalese (if that's at all
possible)?


Do you know of any other communities that are like-minded with you,
that are sticking with GPLv2, that I could poll about interest in such
a provision in GPLv3?


Thanks, and sorry for taking your attention away from coding one more
time.  I hope you find it worth it this time.

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ