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]
Date:	Mon, 18 Jun 2007 15:20:39 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Greg KH <greg@...ah.com>
Cc:	Al Viro <viro@....linux.org.uk>,
	Daniel Hazelton <dhazelton@...er.net>,
	Bron Gondwana <brong@...tmail.fm>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	debian developer <debiandev@...il.com>, david@...g.hm,
	Tarkan Erimer <tarkan@...one.net.tr>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Jun 18, 2007, Greg KH <greg@...ah.com> wrote:

> On Sun, Jun 17, 2007 at 02:56:24AM -0300, Alexandre Oliva wrote:
>> 
>> If you want your opinions to stand a chance to make a difference, the
>> right place to provide them is gplv3.fsf.org/comments, and time is
>> running short.

> If you honestly think that the "anti-tivo" clause in GPLv3 will be
> removed just because we start to add more comments to that page, then
> you are sorely mistaken.

I agree that adding comments wouldn't accomplish this.

But many objections were about the wording, about cases that perhaps
shouldn't be covered, and these could make a difference.

> From the very _beginning_ of the v3 process the kernel developers
> have showed their objection to that section of the license, and we
> were told, to our face, with no uncertian terms, that it was going
> to stay, in one form or another, no matter what we thought or said
> about it.

This sounds about right.

> So, why would we want to waste our time filling out web forms after
> that?

If you're adamantly favorable to permitting any form of Tivoization
whatsoever, don't bother.

Others who aren't so fundamentalist as to reject anti-tivozation on
ideological grounds, in spite of evidence that such measures would
advance the very pragmatic interests they claim to place above
ideology, might be willing to help shape these provisions so
that they don't hurt those who respect users' freedoms, but accomplish
the goal of keeping Free Software Free.


Seriously, looking only at the downside of anti-tivoization (tivoizer
might turn us down), without even acknowledging that, should the
tivoizer change practice and respect users' freedoms, you'd be able to
get far more contributions from all those users, is typical minimax
strategy.  That's the worst case for the prisoner's dilemma.  That's
not pareto optimal.  It may not be a losing strategy, but it's not the
best strategy for everyone.


Every time you enable someone to disrespect other users' freedoms WRT
your software, you cut yourself out of some contributions that user
could make.  Even if you completely disregard the moral and ethical
aspects of software freedom, the open source mentality inherently
depends on the notion of respect for others' freedoms.  You only reap
the benefits of open source when the user gets the freedoms respected.
That's why preventing people from hiding source code, from using other
technical measures, and from using copyright, patents and
anti-circumvention laws, to stop or decrease the possibility or the
incentive for a user to contribute to your community is not only a
great ethical and moral stance, it is also self-beneficial, in the
very sense that Linus and others claim.


So although I like to highlight the moral and ethical aspects, and
others like to highlight the self-beneficial mechanics of the system,
they are really two sides of the same coin.

And if you didn't think so, if you didn't believe in increasing the
incentive and enablement for a user to cooperate with you by means of
stopping others from removing such incentive or possibilities, you
wouldn't be using a license that established such conditions, you'd be
using a more liberal license.

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