Linus Torvalds wrote:
On Thu, 2 Feb 2006, Pierre Ossman wrote:
The point is not only getting access to the source code, but also being able
to change it. Being able to freely study the code is only half of the beauty
of the GPL. The other half, being able to change it, can be very effectively
stopped using DRM.
No it cannot.
Sure, DRM may mean that you can not _install_ or _run_ your changes on
somebody elses hardware. But it in no way changes the fact that you got
I don't consider things I've bought to be somebody elses hardware. The
whole attitude of the big manufacturer that kindly gives me permission
to use their product only how they see fit is very disgusting to me.
The difference? The hardware may only run signed kernels. The fact that
the hardware is closed is a _hardware_ license issue. Not a software
license issue. I'd suggest you take it up with your hardware vendor, and
quite possibly just decide to not buy the hardware. Vote with your feet.
Join the OpenCores groups. Make your own FPGA's.
I'm concerned that in a few years time such systems will be rare and
hard to come by (possibly even illegal). I find such system pissing all
over the spirit of the GPL. To me, the GPL has always been about the
freedom of modifying (in place, not making a clone).
It's a fine line before we are in the territory of restricting what
software can be used for. But for me this is not about restricting their
rights as much as it is preventing them from restricting mine.
And it's important to realize that signed kernels that you can't run in
modified form under certain circumstances is not at all a bad idea in many
cases.
For example, distributions signing the kernel modules (that are
distributed under the GPL) that _they_ have compiled, and having their
kernels either refuse to load them entirely (under a "secure policy") or
marking the resulting kernel as "Tainted" (under a "less secure" policy)
is a GOOD THING.
I dislike the former but the latter is acceptable (and, as you say, in
some cases desirable). There is a big difference between refusing to run
and printing/logging warnings.
Notice how the current GPLv3 draft pretty clearly says that Red Hat would
have to distribute their private keys so that anybody sign their own
versions of the modules they recompile, in order to re-create their own
versions of the signed binaries that Red Hat creates. That's INSANE.
Btw, what about signed RPM archives? How well do you think a secure
auto-updater would work if it cannot trust digital signatures?
I'm arguing the principle here, not the wording of the current draft.
Signatures that are required for execution should be covered, those that
result in warnings should not be. Imagine the shit storm if Red Hat
decided to ship an rpm that didn't allow packages that weren't signed by
them.
It's basically about control. I do not find it reasonable to allow the
vendor control of what goes or not on systems I've bought. They're free
to put systems in place so they can detect that I've fiddled with it so
they can deny me support. But if they want to make a completely closed
system then they'll have to develop it on their own and not use my code.
"Look but don't touch" is not sufficient for me.
Rgds
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]