On Sun, 2006-08-06 at 00:12 +0200, Nacho Barrientos Arias wrote: > I was thinking about package it for Debian GNU/Linux, but i found a > licence issue. You have a GPL program (live-f1) linking with OpenSSL. > This is only ok if you gave a license exception for this otherwise > the two licenses are incompatible and i didn't find any note in your > COPYING file talking about this stuff. > I disagree; I do not believe the GPL can cover dynamic linking. Dynamic linking is mapping two separate binary objects into memory and overlaying runtime-generated references based on a common interface of string symbol names, *NOT* producing any kind of combined object file on disk.
I do not agree that dynamic linking to a library and usage of its public, defined, interface is *any* different from spawning a shell utility (such as sed) and using that interface. I would argue that Live-F1 using the common interface provided by OpenSSL is simple usage of the library, and cannot possibly constitute derivation or copying ... therefore is absolutely out of scope for a copyright licence. In addition, Live-F1 does *NOT* directly use OpenSSL but instead links to a library that happens to link to it; libneon, licenced under the LGPL. Whether or not it links to OpenSSL is simply an internal implementation detail of libneon. Live-F1 does not use any OpenSSL symbols, and itself contains no requirement on OpenSSL, it just happens to use libneon symbols that are implemented using OpenSSL at the moment. I would therefore ALSO argue that even if the OpenSSL author believes that dynamic linking amounts to derivation[0], then the fault is in the libneon library packages and not Live-F1. > I will be very grateful if you take a look to this pages: > > http://www.openssl.org/support/faq.html#LEGAL2 > Note that this does not answer the question as to whether the OpenSSL copyright holders believe that dynamic linking constitutes derivation or a mere temporary aggregation caused by the user and entirely devoid of any "copying". libneon does not provide an exception that anything linked to *it* may be linked to OpenSSL. But then such an exception would be folly, one could implement a tiny libopenssl_dfsg library that re-exports all the symbols and is licenced with an exception. Even without the folly exception, one could write a openssl_wrapper binary that exported all the symbols using command-line switches and a file protocol and a libopenssl_wrapper library that used that interface. This should somewhat go to identifying why I disagree with Debian and the FSF's policy on dynamic linking and the GPL. I can appreciate that this is a thorny issue, however I believe the problem is Debian's making through an entirely-too-strict interpretation of licence terms at the cost of users. I can certainly say that I, as the copyright holder of Live-F1, will never claim a licence breach for the code being dynamically linked to non-GPL code through a publically defined interface[1]. Probably also worth pointing out that users may not even have the right to use Live-F1, as the data it manipulates is under unclear licence terms. I haven't yet had a knock on the door from Bernie's lawyers, but that's not necessarily telling. Scott [0] Which is his right to challenge in a court, after all, he's the copyright holder of the code [1] I do not see the usually claimed "loop-hole" that somebody could take the Live-F1 code, stick it in a library, and wrap it in a proprietary application as a problem. Provided the library interface is public and the code inside that remains open source, it is no different to modifying the code to accept commands on stdin and output to stdout, and wrap it the same way. -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
