Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Tue, 2006-05-23 at 21:13 +0200, Bas Wijnen wrote:
> > The argument that you are actually making is much more subtle (and, I
> > think, more powerful):
> > 
> > If we can build a sufficiently large *collective* block of users who
> > refuse DRM -- big enough that these users represent a noticeable
> > proportion of market share or a publicly visible group whose visibility
> > imposes noticeable embarrassment or noticeable marketing and PR costs to
> > the content providers, we *may* be able to restore more balance of power
> > to the viewers (either through the market or through legislation), and
> > by doing this we may be able to force DRM use to a more acceptable
> > middle position or even eliminate it entirely.
> 
> This is almost the argument, indeed.  Except that I'm assuming that real DRM
> (with protection against the machine owner) doesn't exist yet, and we can make
> it possible.  So I'm not building a group of people who refuse it, I'm trying
> to avoid building a group of people who accept it.

Good. This is a very important clarification. The problem (in practice)
with this is that there are other active (non-Hurd) efforts that will be
in the field either at the same time or before the Hurd that will
succeed at enforcing DRM for practical purposes.

> > 1. RMS is mistaken about a detail: the source of DRM compatibility in
> >    Coyotos is *not* the constructor per se. It is the combination of the
> >    constructor logic and the requirement of opaque storage.
> 
> I'm not sure if RMS is mistaken, because I don't know what he thinks exactly,
> but I agree with you.  I presume RMS considers "the constructor as in EROS",
> which requires opaque storage by default, to be the source.  This is true as
> well (although opaque storage without a constructor is just as bad).

I was paraphrasing Marcus's statement that RMS immediately saw
constructors as a problem. The essential point here is that the
constructor per se isn't the real source of the problem.

> >    Viewed from a purely technical perspective, Marcus's proposed technical
> >    fix is quite brilliant (which is part of why I have struggled with it so
> >    hard -- it is very elegant, and for Coyotos-OS objectives, extremely
> >    damaging).
> 
> Why is it damaging?  I think (if you include the opaque storage in the way I
> described) everything you wanted to do is still possible.  Except allowing
> programmers (without an account on the system) to make agreements with users.
> They can only make agreements when they sell the software, they cannot enforce
> that the agreements are actually kept.  That is good IMO...

Yes. This is the essence of our difference in objectives. I do not agree
that this is good, and Coyotos-OS will not undermine these agreements.
On the contrary, it is a design objective of Coyotos-OS to support them
well for the first time because I (and others) believe that a very wide
range of valid and socially liberating *economic* interactions are
enabled by doing so.

I do not believe that it is profitable for us to debate my view on this.
We will waste a lot of bandwidth and time, and we will not converge.

> ... the
> programmer is not an entity which needs protection by the system.

This is precisely the point on which we disagree. Some of the
applications that I have in mind are *exactly* applications where the
programmer's interests require protection by the system from the
administrator.

I am not arguing here that Hurd-OS should change anything. I am trying
to clarify where the differences in our design objectives lie. This is
important so that we can all understand where the areas are that can be
cooperative and where the lines of divergence exist that lead to
differences in the systems we are building.

At one point, Marcus asked me at LSM why I use the term "Open Source"
rather than the term "FLOSS". The simple answer is that the term "FLOSS"
hasn't really taken hold in the US yet. The more serious answer is that
open source to me is a business strategy, not an ideological commitment.

> > For Coyotos-OS, I will need to retain the mechanism supporting space bank
> > opacity.
> 
> Are you sure about this.  The only thing that this allows is to hide
> information from the common parent of the client and the server (because the
> server will refuse to use storage that isn't authenticated by its own parent).
> Is there any reason this is useful?

Yes, I am quite sure about this. Like I said: different objectives.



shap