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: <or1wg4hawh.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Fri, 22 Jun 2007 01:26:54 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Al Viro <viro@....linux.org.uk>
Cc:	davids@...master.com,
	"Linux-Kernel\@Vger. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

On Jun 21, 2007, Al Viro <viro@....linux.org.uk> wrote:

> On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
>> Do you agree that if there's any single contributor who thinks it
>> can't be tivoized, and he manages his opinion to prevail in court
>> against a copyright holder, then it can't?  That this is the same
>> privilege to veto additional permissions that Al Viro has just
>> claimed?

> You know, I'm rapidly losing any respect for your integrity.  The only
> "privelege" claimed is that of not relicensing one's contributions.

No, this thread was about additional permissions to combine with other
licenses.  I didn't suggest anything about relicensing whatsoever,
that's all noise out of not understanding the suggestion.

You objected to granting additional permissions.  You have that right,
per copyright law, and the other developers can then decide between
not granting an additional permission or removing all the code you
contributed such that they can.  That's veto.

Similarly, if someone proposed an additional unambiguous permission to
tivoize under GPLv2, any developer who objected to it could veto it
(the alternative being to remove all of his contributions).

> What really gets me is that you know it.

Yes.  The only disagreement is that I'm talking "additional permission
to combine" and you seem to keep understanding "relicensing", even
though these are very different concepts, with significantly different
consequences.

What they have in common is that you can veto either one with your
status as copyright holder, and that they would both permit some forms
of cooperation.

Permission to relicense would provide for one-way cooperation out of
Linux.  I'm not proposing this.  That would be stupid.  You've already
decided about it.  I respect that decision.  I even understand why you
made that decision.

Relicensing would provide for two-way cooperation, but under terms
that you don't consider acceptable.  You've pretty much already
decided not to do it.  I respect that decision.  I even understand why
you made that decision.

Permission to combine in both sides would provide for two-way
cooperation in ways that enable each author to enforce the terms s/he
chose for his/her own contributions.  This would address many of the
concerns raised about relicensing, and would increase the amount of
contributions in kind you can get.

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