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?
Attachment:
signature.asc
Description: This is a digitally signed message part