Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Fri, 2006-05-19 at 13:50 +0200, Marcus Brinkmann wrote:
> 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.

These are not intended to be caricatures. They are an honest attempt to have
a discussion in order to clearly understand how your position extends the
position of GPL. If we are going to go further than GPL, I want to
understand how. It is very disturbing to me that you are unwilling to
openly discuss this.

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

Yes. This is precisely my point. GPL accepts that the correct
application of principles is context dependent. It does not attempt to
mandate particular technical decisions that preempt user choice in
advance of understanding circumstances.

I believe that the same approach is appropriate for DRM.

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

First let me explain what I meant by "it is all voluntary": the user can
front-end an opaque bank with a wrapper that records allocations. The
program can refuse to run from such a wrapped bank. Choice is preserved
on both sides.

I do not believe that the design you propose preserves choice in this
sense. If I am mistaken, I would be interested to hear a description of
how these choices on both sides are recovered in your design.

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

I am aware that you have discussed DRM with Richard. Have you discussed
this transparency proposal specifically? Richard is very good at
thinking these things through. He may see implications that we do not. I
do not propose to preempt you. I do suggest that we have an individual
available who is very good at this sort of analysis, and it seems
foolish not to ask.

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

Actually, I think this particular sentence is free of content. A license
cannot grant rights that are not permitted under law, and the mode of
distribution of software does not relate to the execution-time behavior
of that software.

The portion that is clearer (in my mind) on this subject comes later:

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

Even this, however, doesn't disable DRM. One of the beauties and challenges
of DRM is that I can completely open source the protecting program, and
I can allow you to replicate it to any degree you wish, and I can allow
you to use your replicate to attempt to access the content. The TPM
mechanism will protect the content owner.

Note: I am not taking a position here on whether this is good. I am
trying to state an opinion that the wording, as written, may not achieve
the intended goal.

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

That is certainly the intention of the text. I'm just not sure they got
it right.


shap