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

Re: The draft Position statement on the GFDL



Scripsit Raul Miller <moth@debian.org>
> > > And in which jurisdiction can the supplier of Palladium legally forbid
> > > the third party that I give my modified GCC to (and who does not have
> > > any contractual relation with the supplier) from continuing my
> > > development work?
> 
> > If the functionality in question is interoperation with proprietary
> > palladium features, and if everyone who has palladium has to buy into
> > a license that says they won't try to reverse engineer those features,
> > what would this matter?

On Thu, May 13, 2004 at 08:44:51PM +0100, Henning Makholm wrote:
> I still don't see your point. You have never explained how "reverse
> engineering" enters the example at all.
> 
> I already asked you once to present an entire example with every step
> in you argumentation explained, instead of just presenting one little
> extera non-sequitur in each message and expect the readers to fill in
> the blanks.

Oh?

This is the first post I've received from you that contains the word
"step".

I'll try the step by step approach.

The system in question is totally proprietary with special hardware and
software enforcement mechanisms:

[1] Programs and content must be encrypted against a special key or
platform will refuse to recognize them.

[2] Hardware is not sold, only leased, the terms of the lease state that
you will not reverse engineer any part of the system nor will you allow
anyone who has not signed the lease agreement access to the system.

[3] Each computer has a unique private key.   The terms of the lease
state that you will not attempt to discover this private key.

[4] Programs must be signed by the public key of that computer or they
will not run at all.

[5] The key signing algorithm is proprietary.

[6] Programs and content must be signed by a vendor key as well.  To use
programs and content from a vendor, you must have a valid contract
installed for that vendor.

[7] A contract contains the public key of the vendor, a start date and
an end date.  The contract is valid only between the start date and the
end date.

[8] For development machines you can buy the to sign and run programs on
the same machine (but no other machine -- a vendor license is required
for the software to manage contracts and to sign software for specific
machines).  To buy the development package you have to sign an agreement
not to develop any free software.

[9] It's also possible to mark content and programs such that use of
that part of that file debits a micropayment account (with some bells
and whistles so the user can approve the payments).

[10] There are some rules about how micropayments work -- each
micropayment marker has a unique id, and an associated duration.  Once a
program references the marked section, no further debits happen against
that id till after the duration expires.

[11] The code to insert micropayment marks is not a part of the
development, you have to buy that separately.  The terms of the license
repeate all the terms on the lease agreement and all the terms on the
development package.

For flavor, imagine that in addition to being a general purpose computer,
that this is also a platform for watching movies and playing extremely
high-end games, and that most major studios were producing exclusive
content for this platform.

A claim was made that the GPL allows any functional changes be made to
the GPL licensed software.

How do you modify gcc to support this micropayment functionality while
complying with the GPL?

I'm claiming that you can't.  [And probably shouldn't.]

-- 
Raul



Reply to: