[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