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

Re: [dvd-discuss] SSSCA Hearing on Oct. 25





Noah silva wrote:
> 
> Yes, but it simply says the "software" has to contain the protection
> measures.  The source coming with the software may have the practical
> effect of making modification easier, but I don't see how it has a legal
> effect of any kind.  if the kernel comes with the protection and I edit
> the source and disable it, then I am the one doing the illegal thing, not
> the distributor of the kernel, no?  this is a much better position to be
> in because the "enforcer" who wants to keep this protection has to go
> after every user instead of some convenient company.

If you look at the licensing terms and liabilities for these "technical
protective meausures" it is very clear that NOONE could release a
product with such easy hackability.  Look at the extremes IBM had to go
to in order to release a DVD Linux laptop.  It included Macrovision
hardware and special binary only drivers.  Noone would actually buy this
as it would be a "time-capsule" as the owner could not keep up with the
ongoing upgrades to Linux for fear of breaking the driver.

Also, if I release software that is so readily hacked, how can it be
reasonably considered secure.  Security measures typically must be
widely dispersed throughout a system to give the crackers even the
slightest challenge.

Linux kernel code with "#ifdef SSSCA_RULES" would certainly NOT be good
enough.  Further how can one add security to open, read, write, memcpy,
strcpy?  How about the debugger?  Can an open operating system survive
if released code cannot be debugged?

This is the sharp edge of the wedge leading to Stallman's distopia (no
right to read).

.002