l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Part 2: System Structure


From: Marcus Brinkmann
Subject: Re: Part 2: System Structure
Date: Fri, 19 May 2006 13:50:30 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 16 May 2006 10:16:47 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> I am very very concerned about the extremist ideology of transparency
> here. This goes ORDERS OF MAGNITUDE beyond what is required by GPL or
> FSF. GPL does not say "if you run my program, you must disclose all of
> your data". It does not even say "if you modify my program, you must
> give away the modifications".

These are all caricatures of things that have been said.  Nobody said
anything like that, so there is no need to comment.

> It says: if you *redistribute* the
> modifications *then* you must disclose. It notably does NOT say that if
> you connect two programs that you run with an IPC pipe then you must
> disclose.

But it does also not say that if you connect them only with an IPC
pipe then you do not need to disclose.  In fact, it does not say
anything about mechanisms.  The intent is to get maximum protection by
law.  A court will look at all the circumstances and the intent of the
involved parties.

> GPL works extremely hard to strike a careful balance between privacy and
> disclosure. It is instructive to note that it protects *both* very
> strongly. Just as I cannot modify GPL to reduce your obligations of
> disclosure, I also cannot modify GPL to *increase* your obligation of
> exposure. Another way to say this is that I cannot modify GPL to
> *decrease* your right of privacy in the context of private use. I cannot
> narrow the conditions under which privacy holds.
> 
> The "no encapsulation" or "transparent storage" policy is fundamentally
> a step that increases the users obligation to disclosure by reducing the
> conditions under which private execution can be accomplished.

Your position is inconsistent.  When I pointed out to you that the
opaque storage policy decreases the rights of the user, your response
was that it's all voluntary, so there is no problem.  Well, I do not
agree with this argument, but because it is your argument, let me
float it back to you: It's all voluntary.  There is no obligation to
anybody imposed by any policy we make up for the design of the
operating system that we write.

There may be obligations imposed by the GPL v2 and the upcoming GPL v3.

> It is based on an assumption that the conditions under which privacy
> should hold should be narrowed greatly, and that users of GPL
> software should, by default, be required to publish their uses.

That's not an assumption I am making.  However, I may have a different
understanding of what "private" means.  There is an old discussion if
use of a GPL-derived work within a company constitutes distribution or
private use.  As far as I know, this discussion has not been
conclusive.  However, it is pretty clear to me that as soon as more
than one company is involved, or a company and customers, or people
not closely related by family (like, living in one house), one is
leaving the private area.

> I believe that this proposal fundamentally violates the privacy
> protections that are built into the GPL, and I question whether it is
> appropriate for an FSF-hosted project to do that.

Jonathan, I am in contact with Richard on these issues since last
autumn.  I have probably exchanged a hundred emails with him on this
subject matter.  As a result, I have a pretty good idea what the FSF
policy on these matters are, as far as they are articulated.  This
idea is not perfect, because the matters are complex and the
discussion has not been exhaustive.  I am not representing the FSF.
But if you have any doubts that what I am doing here could be
inappropriate for an FSF-hosted project, I would encourage you to
contact Richard and talk to him about it.  He is taking a keen
interest in these matters.

Because the DRM threat is relatively new, we have to look at the GPL
v3 draft to find out the intent of the FSF, because the GPL v2 does
not speak on these issues.  The new draft contains the following
language:

 "As a free software license, this License intrinsically disfavors
 technical attempts to restrict users' freedom to copy, modify, and
 share copyrighted works. Each of its provisions shall be interpreted
 in light of this specific declaration of the licensor's intent.
 Regardless of any other provision of this license, no permission is
 given to distribute covered works that illegally invade users'
 privacy, nor for modes of distribution that deny users that run
 covered works the full exercise of the legal rights granted by this
 License.

 No covered work constitutes part of an effective technological
 protection measure: that is to say, distribution of a covered work as
 part of a system to generate or access certain data constitutes
 general permission at least for development, distribution and use,
 under this License, of other software capable of accessing the same
 data."  http://gplv3.fsf.org/

The sentence "No permission is given for modes of distribution that
deny users that run covered works the full exercise of the legal
rights granted by this License" is pretty clear.  There are legal
questions involved, for example if copying a program over the network
from a provider to a client constitutes distribution, or if requesting
a constructor constitutes "running the program", but I think that the
answer to both questions may very well be given as "yes" by a court,
especially if it looks at the intent of the parties involved.

The second paragraph has a slightly different twist to it.  It
specifically forbids to use covered works for things like locked-down
gaming consoles or other proprietary devices, which do not allow
changes be made by the owner.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]