Licence text and fabs
Posted Oct 2, 2006 23:38 UTC (Mon) by
mingo (subscriber, #31122)
In reply to:
Licence text and fabs by stevenj
Parent article:
Busy busy busybox
That's a bad example, because that's not forbidden by the GPLv3. Making the hardware look at, say, the MD5 hash of the kernel before running it does not require any secret encryption keys.
Firstly, i did not talk about an MD5 hash of the kernel.
Secondly, read the GPLv3 draft again, it is not limited to "secret encryption keys" alone. See Section 1:
The Corresponding Source also includes any encryption or
authorization keys necessary to install and/or execute modified
versions from source code in the recommended or principal context of
use, such that they can implement all the same functionality in the
same range of circumstances.
(emphasis added)
Note the "encryption or authorization" language. It is not limited to encryption keys alone.
Anyway, what does the "key" have to do in the definition of source code? By putting this into the Source Code definition, we are implicitly judging the act of "not sharing a key" immoral - because it's now judged to be an act of "not sharing the source code". (The GPLv3 does carve out a few exceptions in later sections, but the damage has already been done in this section.)
As it has been acknowledged by another poster here who seems to be intimately familiar with the GPLv3 process, the goal of this definition is to dictate what the hardware does, to remove the inconvenience of certain types of hardware limitations. My observation is that the GPLv2 did not do this, never tried to do this, and that trying to control what hardware does is immoral. (and pointless btw., as i explained it in other replies in this thread.)
What "inconvenience" will we try to remove via the license come GPLv4? Perhaps the inconvenience of not getting money in exchange of the nice free software we are writing?
(
Log in to post comments)