<br><br><div><span class="gmail_quote">On 8/15/07, <b class="gmail_sendername">Chris Travers</b> <<a href="mailto:chris@metatrontech.com">chris@metatrontech.com</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 guess I sent my concerns some time before I was actually subscribed.<br>If they come through separately, I appologize for the re-post.<br><br>I see a number of possible issues with the GPL v3. I will list them with<br>the sections of the OSD here:
</blockquote><div><br>It is good to use the OSD  in your analysis, because that is the one relevant reference.<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;">
6: No discrimination against fields of endeavor:<br>The license must not restrict anyone from making use of the program in a<br>specific field of endeavor. For example, it may not restrict the program<br>from being used in a business, or from being used for genetic research.
<br><br>I think that the anti-Tivoization provision in the GPL v3 effectively<br>prevent its use (or at best are not technology-neutral regarding its<br>use) in areas such as, say, WIFI card firmware, or the like where the
<br>hardware/software package is subject to sufficient regulation as to<br>prevent the user from being able to make arbitrary modifications ot the<br>code and still run it on that specific piece of hardware.</blockquote><div>
<br>I don't accept this logic.  In my view it's not the GPLv3 that's restricting the field of endeavor.  There's a wholly separate regulatory regime that does or does not permit the operation of certain devices in certain environments.  The OSD focuses on what the license does or does not allow, not what unrelated governing law does or does not allow.  Last time I checked, it's not legal to construct an operable nuclear warhead in the US, but that prohibition does not invalidate any OSI-approved license that might cover software capable of triggering such a device.
<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;">9: License must not restrict other software<br>The license must not place restrictions on other software that is
<br>distributed along with the licensed software. For example, the license<br>must not insist that all other programs distributed on the same medium<br>must be open-source software.<br><br>I suspect there are *cases* where the GPL (both versions 2 and 3) fail
<br>in this regard, particularly where works which might be considered<br>separate when distributed separately might be considered the same work<br>when distributed together. I don't see this as an obstacle, but want to
<br>mention it anyway. See below.</blockquote><div><br>I did see below, and my analsys is that modifyable software shipped with hardware does not make hardware a derived work of the software, and so I think your concern is moot.  I elaborate below...
<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;">10: License must be technology-neutral<br>No provision of the license may be predicated on any individual
<br>technology or style of interface.<br><br>There are GPL v3 provisions which are predicated on the distribution of<br>software in restricted environments being limited to ROMs.</blockquote><div><br>I think you have this backward: if  the software is distributed in ROM, some requirements do not apply.  I am not a lawyer, but if something does not apply, it's not a provision, but the opposite.
<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;">Further Discussion and Recommendations:<br><br>OSD Sections 6 and 10 vs the anti-Tivoization provisions in the GPL v3.
<br>The GPL v3 added provisions which require one who conveys GPL v3<br>software with a user product (such as a Tivo) to provide installation<br>instructions sufficient to get user-modified software running on the<br>system. The direct target of this change was Tivo, but the larger
<br>concern appears to be the interplay between software and hardware. In<br>essence the GPL v3 requires that these are treated as entirely separate<br>goods unless the software is distributed via a method whereby nobody has
<br>the ability to change it (for example, a ROM). The intent was to prevent<br>GPL v3 software from being used in unTrustworthy Computing platforms in<br>a way which were not fully usable when the source was changed by the end
<br>user.</blockquote><div><br>From above: I would construe this differently.  I would say that the requirement to supply sufficient instructions ensures that users are not denied the freedoms that a vendor might enjoy.  To the extent the vendor has the ability to modify the software, the user should have the same rights, and those rights should not be obscured by technical obscurity/interference.  To the extent that the vendor has no ability to change software on a device they supply, the are not liable to provide the user with any such ability, either.  Thus, this is a question of symmetry of rights.
<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;">The relevant section of the license is: [...]<br><br><br>As a side effect, this effectively bans the use of GPL v3 code in any
<br>device which requires government certification of the hardware/software<br>package (such as a WIFI card and related firmware). It could also<br>prohibit use of GPL v3 software in voting machines in that it would be<br>
illegal for the counties that use the machines (and hence distribute the<br>software) to prohibit modifications of the software through technical or<br>legal means. In fact the only option open in these cases is to remove
<br>the ability to do any vendor updates (including security updates) from<br>the products in question and hence take on a substantial competitive<br>handicap.</blockquote><div><br>If your interpretation were correct, which I do not think it is, then one positive effect of the GPLv3 (but also the GPLv2) that it would provide standing to people to sue the government to allow people to modify such software.  This would benefit society because often bugs are found via stress-testing and whitebox testing.  A law prohibiting any modification of software on voting machines would make it impossible for independent audit of the machines, which can lead to abuse.  But the more relevant question is: how does this violate the OSD...I do not see how.
<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;">I would recommend that the FSF drop the questionable provision before<br>this is adopted. It violates either portion 6 or 10 of the OSD by my
<br>reading, depending on how I read the OSD and the GPL v3.</blockquote><div><br>I do not agree.<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;">
As for OSD section 9: There are cases where the GPL, versions 2 and 3<br>may affect other software on the same media even when it might not were<br>they separate.</blockquote><div><br>Please provide an example.  I know of none such. 
<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;">IANAL, but I see a few cases where this could happen. I will draw<br>parallels between existing cases in the GPL v2 in this section, however.
<br><br>For code to fall under the GPL licensing requirements when linking to a<br>GPL application, it would need to be either a) derivative of that GPL<br>application or b) part of the same "covered work." If neither of these
<br>apply, then the GPL licensing requirements don't apply either.</blockquote><div><br>So far I'm with you (meaning I agree that it's possible for code to be linked but not have the GPL provisions apply--your third case). 
<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;">For example, ndiswrapper provides, under a GPL-compatible license, a way<br>of linking NDIS Windows drivers (closed source) to the GPL v2-licensed
<br>Linux kernel. I do not believe that this is a GPL violation when the<br>Windows drivers are distributed separately because they are not<br>derivative of the Linux kernel nor are they by any reasonable measure<br>part of the same work just (being independantly written and distributed).
</blockquote><div><br>Therefore, they are not a derived work.<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;">A similar case I believe exists with regard to the nVidia closed source
<br>drivers for Linux. Again, the proprietary code is non-derivative, a<br>compatibly-licensed bridge exists, and the software is distributed<br>seprately. (This same argument might *not* apply to the Apple ObjC<br>plugins for the GCC because it is not clear to me that these were
<br>written for another environment and that a compatibly licensed bridge<br>existed.)<br><br>However, what happens now when I pre-install those same nVidia or wifi<br>drivers on a Linux-based laptop that I sell? Can it then be argued that
<br>I am, in distributing both the closed source and open source packages<br>together essentially creating a new "covered work" based on the "Linux<br>kernel" but that license incompatibilities forbid me from distributing
<br>it? In short, there are cases where mere aggregation *may* under the GNU<br>GPL (versions 2 or 3) create new covered works which hold a distributor<br>liable for copyright infringement even when the original developers are not.
</blockquote><div><br>IANAL, but I don't believe such distribution transforms somebody's proprietary blob into a derived work.  The reason that Fedora (a free/open source Linux distribution) doesn't distribute proprietary drivers is not because of the derivative work problem (which I don't think you have proved is a real problem), but because their commitment to 100% pure free/open source is not met by shipping proprietary codes.  There are vendors out there who *do* ship proprietary drivers with their Linux distribution, and I don't believe they are violating the GPL.  They *are* violating what it means to be 100% pure, but that's a marketing decision, not a legal one.
<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;">However, the fact is, the GNU GPL v2 has been accepted as an<br>OSI-compatible license for some time and the GNU GPL defines source code
<br>and covered work a little more tightly than does the GPL v2. Therefore<br>the GPL v3 is an improvement in this case and I believe it would be<br>inconsistant of this organization to let this specific problem (of OSD<br>
part 9) get in the way of approval. I would therefore hope the OSI would:<br><br>1) State specifically that definition 9 does not apply to cases where<br>these problems only exist in corner cases.</blockquote><div><br>It's not our position to render legal advice like this.  Only a lawyer can do that. We can say what we believe the OSD requires or does not require, but we cannot speak to the legal behavior of a license in an as-yet unknown corner case.
<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;">2) Thank the FSF for helping to reduce the impact of this problem in<br>version 3 of this license.
</blockquote><div><br>I certainly would like to see the Board do this.<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;">I would therefore suggest that we consider either clarifying why the GPL
<br>does not erode or volate OSD sections 6 and 10, or ask that they drop<br>the anti-Tivoization clauses prior to approval.</blockquote><div><br>Hopefully I have clarified why I think the GPLv3 fits within OSD 6 and 10. 
<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;">Best WIshes,<br>Chris Travers<br><br></blockquote></div><br>Thanks for submitting a detailed opinion.  Though I did not agree with some of your points, I applaud your effort to write it out and engage with us.
<br><br>M<br>