[Dnsmasq-discuss] GPL v3
richardvoigt at gmail.com
richardvoigt at gmail.com
Fri Sep 14 02:00:35 BST 2007
On 9/13/07, Mike Baker <mbm at openwrt.org> wrote:
> I've never really understood the concept of "gpl version x or later",
> particularly now that there are incompatibilities between the gpl
> Any time you apply more than one license or version you're running the
> risk that someone will fork the project or send in patches under the
> more restrictive license. If the project was "version 2 or later" and
> someone decided to write a few patches and release a new build as
> "version 3 or later" you would be unable to merge these patches back
> into the "version 2" code. At this point your options are to beg to get
> the patches relicensed as "version 2 or later" so they can be merged,
> switch the license of the main project to "version 3" (or later), or be
> forced to ignore the patches. It all seems rather counter productive.
> As to the specifics of the gpl v2/v3 debate, the main issue seems to be
> the $(TIVO) clase; "Installation information" found at the end of
> section 6 which only applies to a "User product". The clause states that
> for any household product, the sources need to be accompanied by
> installation instructions detailing how to to install the modified
> binaries. Unfortunately, this is a headache for most embedded
> programmers since it's common practice to sign or encrypt the firmware
> and store the encryption keys in the bios. The reason behind this is
> that while the device contains gpl'd software, it also contains
> proprietary software; the keys are to protect the proprietary
Signing and encryption have very different intent. Encryption does protect
proprietary software. The bios would only contain the decryption keys,
however, and the encryption keys could be freely distributed without
compromising the software.
Signing is designed to restrict the hardware. It doesn't actually protect
the proprietary software, except to the extent that the user can't upload
code that would read the system ROM and send it back, but reading is almost
always possible without changing the code anyway.
Additionally, it is quite straightforward to partition the ROM and only
encrypt/decrypt the bootloader and proprietary part, while allowing the open
source part to be made available.
Remember that it doesn't have to be possible to replace arbitrary portions
of the system, only the GPL parts. It is perfectly acceptable for the
company to make available a ROM builder tool that includes an encrypted
block which it concatenates with the user-compiled customizations.
While I really don't want to be dragged into a debate about the TIVO
> clause, I think it's important to point it out. If the authors feel that
> they've been screwed by a (certain) commercial company leveraging their
> project, they can relicense as gpl v3 to prevent it to some extent, but
> as soon as the software is licensed as v3 it will block (any) commercial
> developers from being able to (use and) contribute to the project; the
> double-edged sword that Kaloz made reference to in a previous email.
It won't prevent commercial developers from using it, it does raise the cost
of doing so, but Simon isn't compelled to give his software away free of
restrictions. I suspect more than a few companies would feel that the value
of using a well-debugged dnsmasq with future upgrades and community support
to outweigh the cost of supporting unencrypted blocks in the bios and
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dnsmasq-discuss