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:	Fri, 15 Jun 2007 19:52:22 -0500
From:	"Scott Preece" <sepreece@...il.com>
To:	"Alexandre Oliva" <aoliva@...hat.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "Rob Landley" <rob@...dley.net>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Daniel Hazelton" <dhazelton@...er.net>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Greg KH" <greg@...ah.com>,
	"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 6/15/07, Alexandre Oliva <aoliva@...hat.com> wrote:
> On Jun 15, 2007, "Scott Preece" <sepreece@...il.com> wrote:
>
> >> That's not true.  They can just as well throw the key away and refrain
> >> from modifying the installed software behind the users' back.
>
> > This characterization misses something important.  For many product
> > devices, like cell phones, the modification is never "behind the
> > user's back"
>
> Okay, take out the "behind the users' back", it makes no difference.
> That was just to highlight the frequent evil intentions behind keeping
> the keys.
---

Yes, but in highlighting the possibility of evil intentions you
distort the fact that usually there are no such evil intentions...

---
>
> I wonder if giving half the key to the user and keeping the other half
> would be enough to satisfy the GPLv3 language while still enabling the
> vendor and user to update the software together.
---

I think that's a possibility. I don't see how it's functionally
different from the usual case where the manufacturer can't modify the
device without the user's consent simply because the user has physical
access to the device and the manufacturer doesn't.

---
>
> > The FSF's approval of this distinction (ROM versus replaceable) places
> > the FSF's particular principles over users interests, for no
> > particular reason
>
> Over *users* interest?  How so?
---

Users benefit from the ability to get software updates, from the
manufacturer, to resolve problems, fix security vulnerabilities, and
provide updated functionality.

---
>
> > if the manufacturer believes that it cannot legally allow software
> > modification, all the restriction does is force them either to make
> > the software unmodifiable (which advances freedom not at all) or to
> > use software under a different license (which advances freedom not
> > at all).
>
> Right.
>
>
> But if the manufacturer believes that it can legally allow it, and
> wants to be able to install, software modifications, then it must
> decide between giving that up and letting the user do it as well.  And
> this is where the users interests may prevail.
---

You're harping on the "cannot legally", which is fine but irrelevant.
Whether it's a legal requirement or a business decision, the result is
the same - neither forcing the manufacturer to make the device
non-updatable nor forcing the manufacturer to use different software
benefits anyone. I don't know of interesting cases where the
manufacturer makes the device non-modifiable out of sheer
bloody-mindedness.

I don't believe that the existence of this clause will lead to more
manufacturers making their devices modifiable - there are too many
other options if they think that non-modifiability is important to
them.

[Note that I *do* think it's perfectly appropriate that authors who
feel that they don't want their work used in such devices should be
able to license them in line with that belief. I just don't think it
has any practical value aside from making them feel better.]

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