<br><br><div><span class="gmail_quote">On 9/13/07, <b class="gmail_sendername">Mike Baker</b> <<a href="mailto:mbm@openwrt.org">mbm@openwrt.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've never really understood the concept of "gpl version x or later",<br>particularly now that there are incompatibilities between the gpl<br>versions.<br><br>Any time you apply more than one license or version you're running the
<br>risk that someone will fork the project or send in patches under the<br>more restrictive license. If the project was "version 2 or later" and<br>someone decided to write a few patches and release a new build as
<br>"version 3 or later" you would be unable to merge these patches back<br>into the "version 2" code. At this point your options are to beg to get<br>the patches relicensed as "version 2 or later" so they can be merged,
<br>switch the license of the main project to "version 3" (or later), or be<br>forced to ignore the patches. It all seems rather counter productive.<br><br>As to the specifics of the gpl v2/v3 debate, the main issue seems to be
<br>the $(TIVO) clase; "Installation information" found at the end of<br>section 6 which only applies to a "User product". The clause states that<br>for any household product, the sources need to be accompanied by
<br>installation instructions detailing how to to install the modified<br>binaries. Unfortunately, this is a headache for most embedded<br>programmers since it's common practice to sign or encrypt the firmware<br>and store the encryption keys in the bios. The reason behind this is
<br>that while the device contains gpl'd software, it also contains<br>proprietary software; the keys are to protect the proprietary<br>components.</blockquote><div><br>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.
<br><br>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.
<br><br>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.<br><br>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.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">While I really don't want to be dragged into a debate about the TIVO<br>clause, I think it's important to point it out. If the authors feel that
<br>they've been screwed by a (certain) commercial company leveraging their<br>project, they can relicense as gpl v3 to prevent it to some extent, but<br>as soon as the software is licensed as v3 it will block (any) commercial
<br>developers from being able to (use and) contribute to the project; the<br>double-edged sword that Kaloz made reference to in a previous email.</blockquote><div><br><br>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 bootloader.
<br></div></div>