I haven't read all 700 emails related to this issue, but can someone please explain to me why this statement holds?
> - Binaries linking to FTD2XX may NOT be distributed. Where can I find the FTD2XX license? Thanks, Ronald -------- Original Message -------- Subject: [Openocd-development] OpenOCD, the GPL, and FTD2XX From: Zach Welch <z...@superlucidity.net> To: openocd-development <openocd-development@lists.berlios.de> Date: Tue Jun 23 2009 00:29:11 GMT+0200 (Romance Standard Time) > 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 > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
