Hi all, I will try to summarize the OpenOCD license situation for the community:
- OpenOCD is licensed under the GPL -- without exceptions. - Binaries linking to FTD2XX may NOT be distributed. - Neither static nor shared, direct nor indirect. - There will be no future exceptions to this rule. - Past "violations" will not be pursued, but we expect compliance now. The "best for open source" solution will be to remedy all deficiencies in libusb and libftdi, even if that takes more time and labor. This will provide a fully open source solution for users, which should be preferred by the community of maintainers, contributors, and vendors. Conversely, preference to the proprietary driver as a long-term solution undermines the free software community and the freedoms of its users. Until an open software solution manifests itself, there appear to be two acceptable (if hard) workarounds to distribute binaries to end-users: 1) A "build kit" can be distributed that compiles the source code from scratch on the machine of each user that wants to use the closed FTD2XX driver. This solution can be developed in time for the 0.2.0 release. Is someone already working on one and will share it with the community? 2) A "socket interface driver" that provides generic JTAG driver support can be distributed, to which a completely separate FTD2XX driver can be connected (from its own independent process space). That binary driver could use a small "socket driver" library to manage connections and exchange messages with OpenOCD, but such re-use would be possible if and only if that library is licensed under the LGPL (or similar terms). This could be developed for 0.3.0 or later releases; however, an open source driver solution should be considered the higher priority, because sockets will introduce unavoidable performance penalties. The existing maintainers and contributors have expressed willingness to accept these two solutions to work around the "limitations" of the GPL, so these pass our "GPL filters". It will be less work to implement one of these technical solutions than to continue debating solutions that fall into legal gray areas. Solutions that violate the GPL should not be given further consideration. So, notably absent from this list are any type of "wrapper" library. Several contributors oppose this as an option, particularly as these suggestions appear to derive exclusively from the present desire to circumvent the GPL distribution restrictions. For these reasons, I hope the community will stop considering such solutions. Please let me know if this summary is factual incorrect or incomplete. Sincerely, Zach Welch Corvallis, OR _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
