Nicolas, I figured a simple NACK would not suffice, given the range of topics this thread has covered. This is not all meant for you, as I expect you have heard these arguments once or twice in the past. :) I just wanted to post to this thread once (and for all).
On Mon, 2009-06-15 at 00:28 -0400, Nicolas Pitre wrote: [snip] > Now... who can make that call? Is there someone with code in OpenOCD > who is against such a relicensing? Yes. OpenOCD *is* GPL. I would _not_ have contributed as much as I have to the code, if I thought anyone could later distribute versions with proprietary extensions. I will vehemently oppose and challenge all such use cases, though this statement deserves some clarification. The GPL is about freedom -- to the extent that it forces its "freedoms" down your throat when you distribute GPL-licensed binaries. In that respect, the code is _definitely_ not as "free" as the public domain, but any "lost" freedom assures it remains _more_open_ moving forward. The GPL is better to keep source code open than "open source licenses," at the cost of the freedom to distribute binaries without source code. Since "no exceptions" should now be clear, I would consider distribution of OpenOCD 0.2.0 binaries with support for the FTD2XX libraries as a flagrant violation of the GPL. This express sentiment serves as unequivocal and sufficient warning for anyone who would consider otherwise. I am very sorry if this is a problem; however, those are the consequences of the licensing terms for the respective packages. To me, this was always clear; debate seems moot. With dynamic module loading capabilities, it _might_ be possible to independently distribute a ftd2xx-plugin package, as such would be in a potentially "gray area" that avoids consequences (as you pointed out). Maybe. Personally, I think that would be a GPL violation too, but perhaps I am simply an ideologue backing a Stallmanesque agenda. ;) The community should be discouraged from trying the limits to find out. Others have pointed out that this licensing violation occurs only when distributing the binaries, so I do want to provide assurance that I have no problem supporting these types of features -- for developers to use in local builds _only_. I think such support is great, in fact. Specifically, these kinds of restrictions should not impact OpenOCD's functionality for developers. If libftdi is insufficient, the community should have someone work on improving that code until it performs competitively. The same goes for the underlying libusb support or for any other component lacking a comparable GPL-compatible alternative. For developers, in-tree proprietary solutions give implementations that can be compared with open solutions, to ensure these stay complete and competitive in our code base. Further, forbidding the distribution of these proprietary features helps the community by providing a strong impetus to develop or improve equivalent open source solutions, which leads to pressure on the proprietary vendors to open their libraries. Any feature support is good, but open is better; however, only features "compatible with the GPL" can be distributed in OpenOCD binaries, and proprietary libraries do not fall into this last category. I do not care if this is an unpopular declaration; my obstinance runs deep, though my level of compromise should demonstrate that I stand apart from those that mindlessly follow the GNU Hurd. ;) Sincerely, Zachary T Welch Corvallis, OR P.S. I believe it is possible to deliver a technical solution that would allow a binary FTD2XX solution to be distributed for OpenOCD, sidestepping the present legal hurdles. Such would require a lot of work (much of which would be added to and benefit OpenOCD as GPL code), but the point I want to make is simple. We do not need to change the license when technical loopholes exist that will achieve the same ends. P.P.S. Full disclosure: I am a professional software developer who is looking for "GPL-compatible" work, so I have both vested and immediate interests in promoting more open source software development activities. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
