On Mon, 15 Jun 2009, David Brownell wrote: > No, it's extremely easily defensible. They saw the license was > GNU GPLv2, and they knew just what that means. It's hardly news > to anyone ever looks at licenses. There would be no "retroactive > revocation" going on, to just acknowledge reality by updating the > docs so they don't suggest distributors may violate that license. > (Any distributor with a brain already knew not to do that, but > that doesn't mean anyone should encourage such violations.)
I agree on the distribution angle. Probably no one considered OpenOCD mature enough to matter for actual distribution until now. And with any non Windows system this is a non issue as there is libftdi anyway. > This isn't even what I'd call "fine print" in the legal language. > It's one of the most distinguishing features of the GPL. > > Don't forget that the issue isn't having a "you may optionally > use <closed source library/> in personal builds" option. > > The issue is simply whether someone *DISTRIBUTING* binaries is > allowed to rely on that library. And permission for that has > never been granted, through the license, by any contributor. This position is of course a bit strong. I doubt many people here care that much about using OpenOCD to promote the agenda behind the GPL. Yet, "relying" on a library is not what the GPL says. The GPL talk about redistribution of code and binaries, and the constituents that are _linked_ together to define that binary. If libftd2xx is not statically linked, or even not distributed along with the compiled OpenOCD binary, then the case against it is highly arguable and far from being a black and white picture but rather a large gray spot. Not admitting to this is pure ideology. So I'm all in favor for a patch clarifying the documentation on this point, with the nuance that on Windows it is recommended that llibftd2xx must be installed separately for distribution of OpenOCD to _possibly_ be legal. And the "possibly" is important here so to let lawyers determine it for sure if needed. Nicolas _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
