[OT] RFC for DRM replacement

Mark Rafn dagon at dagon.net
Tue Sep 9 15:21:11 UTC 2003

[sending only to list, assuming interested parties are subscribed.]

> > >Mark Rafn wrote:
> > >>Fundamentally, if the client is open-source, it can be 
> > >>modified, and the 
> > >>modified version can LIE and say it's the original version. 
> > Anything 
> > >>which prevents this is not open-source.
> > Mário Amado Alves answered:
> > >Many (most?, all?) open source licenses require authorship notices
> be kept.

The program doesn't have to lie to humans, only in the API.  It's fine to
require a notice that the work has been changed.  Requiring the form of
that notice, or that the notice be usable for other programs to behave
differently is not open-source. 

On Tue, 9 Sep 2003, James Michael DuPont wrote:
> CUT! 
> We are talking about a malicious user who is modifing the software to
> LIE about the fact it is modified. They wont be telling anyone that
> they did this

I wasn't.  I was talking about an honest open-source user and contributor 
who is free to make a derived work from open-source software.   Of course 
the documentation, and if possible the program itself will make it clear 
that it's modified and based on the original work.  

For some works, this notice cannot be in the place which contains the 
original declaration, because that's part of the API.  Any program which 
tries to restrict workalikes or modified versions that use the same 
protocol or API calls is clearly not in the spirit of open-source.

> My solution is to introduce a game theory, where the game itself is
> changed so often (the key) that it is very hard to crack all of them
> quickly.

If the client is open source, nobody has to crack the key.  It's there in 
the client.

> -------------------------------------------------------------------------------------------------------------------
> http://www.advogato.org/article/698.html
> -------------------------------------------------------------------------------------------------------------------
> 1. There are valid applications where a group of people agree to use
> one version of the software and want to eliminate cheaters. A First
> person shooter for example would be a good example 

Sure.  There are many of them, and it's probably best not to make the 
entire client open-source in that case.  Or distribute keys seperately 
from the program, and give them only to trusted players, revoking them 
when cheating is discovered.

> 2. By allowing for a auditing of the clients on a random basis, and the
> inclusion of the entire memory of the software including of the data at
> a specified timepoint you can get a secure fingerprint that is very
> very difficult to fake. 

As long as the auditing program is trusted to be the original version. 
Which means it's not open source. 

> 3. By allowing for a secondary protocol to use a secure cipher to
> encrypt and slightly change the binary of the file, you can increase
> the cost of binary hacks.

Binary hacks?  I thought this was open-source.

This is a pretty complicated system for something that boils down to "make 
a non-free program that audits the free program."
Mark Rafn    dagon at dagon.net    <http://www.dagon.net/>  
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

More information about the License-discuss mailing list