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:	Thu, 21 Jun 2007 19:13:20 -0700
From:	"David Schwartz" <davids@...master.com>
To:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3


On Jun 21, 2007, aoliva@...hat.com wrote:

> On Jun 21, 2007, david@...g.hm wrote:

> >> For the record, GPLv2 is already meant to accomplish this.  I don't
> >> understand why people who disagree with this stance chose GPLv2.
> >> Isn't "no further restrictions" clear enough?

> > everyone else is reading this as 'no further license restrictions'

> I didn't see anyone else add "license" where you did.  "No further
> restrictions on the rights granted herein" is very powerful and
> extensive, and that's how it was meant to be.

I agree. For example, a patent might impose a further restriction. The GPL
was clearly meant to foreclose that. There are any number of other ways of
nasty, subtle ways to impose further restrictions, and the GPLv2 meant to
foreclose all of them.

> > not no hardware restrictions' becouse GPLv2 explicitly says that it
> > has nothing to do with running the software, only with distributing
> > it.

> It also says that running the software is not restricted, and since
> copyright law in the US doesn't regulate execution, receiving the
> software does grant the recipient the right to run the software.  So
> the distributor can't impose restrictions on it.

Right.

The response to this argument is that it is mind-bogglingly obvious that the
GPL doesn't mean that no *authorization* decisions can stand in your way. It
didn't mean that I couldn't keep the root password to my server secret even
though that denies you the "right" to modify the Linux kernel running on it.

Some entity has to decide what software runs on any particular piece of
hardware, and it was never the intent of the GPL to specify or limit who
that person was. This has been discussed many times over many years, longer
before Tivoization was even thought of, and it was agreed that the GPL
didn't foreclose authorization obstacles to software modification.

Why doesn't Linux allow a non-root user to install a module or change which
kernel the system runs? Doesn't that limit the GPL rights of all non-root
users to modify the GPL'd kernel software on that machine? OF COURSE NOT.

DS


-
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