Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Zach Welch wrote: > 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? > I'm currently trying this approach. I'm trying to build latest SVN head and preparing a simple wrapper GUI based on Qt, though it is a little bit slow on my Windows XP virtual machine. Regards, Caglar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Zach Welch wrote: > On Tue, 2009-06-23 at 01:36 +0300, Yusuf Caglar AKYUZ wrote: >> Zach Welch wrote: >>> 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? >>> >> I'm currently trying this approach. I'm trying to build latest SVN >> head and preparing a simple wrapper GUI based on Qt, though it is a >> little bit slow on my Windows XP virtual machine. > > Excellent!! You will be praised highly for delivering such a solution, > so please keep the community apprised of your progress. > > Out of sheer curiosity: how will your Qt wrapper be licensed? :) :) > Whichever license is appropriate, both for OpenOCD and FTD2XX. LGPL may be? Regards, Caglar > Thanks, > > Zach > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Zach Welch wrote: > Actually, I see no reason that it cannot be GPL too. It's "only" a > build tool; it will not be linking to either OpenOCD or FTD2XX, right? > The full GPL would prevent others from creating proprietary versions of > your tool, which may or may not be what you desire personally; however, > your license does not impact the licenses of what the tool builds. This > is why the "build kit loophole" works: they are totally separate works. > Otherwise, a GPL package manager could only build/install GPL packages! > > Of course, a tool that includes _necessary_ build scripts or components > for building OpenOCD would be forced to be GPL (see the license), but > that is not what we are talking about. Developers have everything they > need to compile everything by hand; you are adding a high-level helper > script that ties it all together for users, so it is not "necessary". > > I hope that others will step forward and correct me if I am wrong on the > details, but I hope this generally helps clarify these particular > licensing details. Either way, I would consider adding it to the > repository in the tools/ directory, if that turns out to be a reasonable > plan of action for all. What do you think about that? > I'm not an OpenOCD user under Windows but a tool like this is not hard to implement so I'm willing to integrate further suggestions from Windows users. When this is a complete solution, I guess it will help to include this in tools dir. Thanks, Caglar > Cheers, > > Zach > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Alain Mouette wrote: > Yusuf Caglar AKYUZ escreveu: >>> Out of sheer curiosity: how will your Qt wrapper be licensed? :) :) >>> >> Whichever license is appropriate, both for OpenOCD and FTD2XX. LGPL >> may be? > > The Qt licence is strict GPL, so it cannot be anything else... > No, not anymore. Please see http://www.qtsoftware.com/downloads. Thanks, Caglar > Alain > > > ___ > 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
Re: [Openocd-development] openocd, ftd2xx
Zach Welch wrote: > On Wed, 2009-06-24 at 20:14 +0100, Ian Guffick wrote: >> >>> Here is the full list of GPL-compliant solutions for libftd2xx GPL >>> compliance, after further review, consideration, and enumeration: >>> >>> 1) Documentation: build it yourself! >>> 2) Build-Kit: automate the build on users' machines >>> 3) XXX: to be revealed, if legal >>> 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx >>> 5) sockets: separate ftd2xx into their own process space >>> 6) libusb+libftdi: The Right Thing To Do ;) >>> >> >> >> Just a thought on option 2 - the build kit. >> This would be a large download, and quite a lot of work for someone to put >> together. >> If the GPL violation happens in distributing code that is linked to FTD2XX, >> could the build kit have pre-compiled objects for openocd - that are then >> linked on the users machine. The pre-compiled objects, as distributed, would >> not be linked to FTD2XX. This would reduce the complexitiy of the build kit >> down to a much simpler 'link-kit'. It's function would be no different to >> the build kit. >> I haven't looked into it but maybe this could be as simple as a few object >> files, LD and a few MingW libraries along with a batch file. > > I think it will take a little bit more effort than this (some autotools > magic to ensure users can build different configurations), but this is a > great idea for reducing the download sizes. In many ways, it sounds a > bit like using ccache; once the cache is populated, you only ever link. > > Cheers, > > Zach > Actually this is a very nice approach. Making only linking process on the user side helps a lot in this case. I suspect this may be easier than we think. This can be even handled in installer scripts like nsis. On the other hand, I have a working build tool at hand, it currently: + Downloads FTD2XX libraries, + Fetches OpenOCD using SVN, + Configures, builds and installs openocd all with a simple wizard so no user interaction is mandatory. However, putting cygwin and gcc into kit makes it very huge in size. It is also possible to download cygwin components without user interaction(cygwin has an installer) however I couldn't manage it to work. I guess, in the end all will be needed on user side is some time and bandwidth. Thanks, Caglar P.S. Current SVN HEAD is not building on Windows, at least I cannot succeed. Configure is unable to test ftd2xx libraries but it is building if I disable checks. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Final Fixes for 0.2.0?
David Brownell wrote: >> does the community know of any reason to hold this countdown? > > Oh, and I'd still like to see the at91sam3 config files > become non-executable. :) > You make me think that next release will be in very far future :) I guess I have skipped the mentioning of this but can anybody repeat for me when will be the 0.3.0? Please forgive my ignorance. Thanks, Caglar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
