Re: Netatalk and OpenSSL licencing

[Freek Dijkstra <debian_public@macfreek.nl>]

On 13-08-2004 0:09, "Josh Triplett" <josh.trip@verizon.net> wrote:

> I think the issue of non-GPL-compatible licenses is certainly annoying,
> but I don't really see any way around it without losing the copyleft.

I see a theoretical and a practical way.


First of all the theoretical way:

I would have preferred that the GPL would be less strict in allowing dynamic
linking of GPL software with non-GPL compatible, but still free software.
Given the list at http://www.gnu.org/licenses/license-list.html, the FSF is
perfectly capable of making the distinction between "free" and "non-free"
(where BSD, Apache, OpenSSL, etc. licences are still considered "free"; thus
basically all licences which force that the source is kept open).
I'm 100% convinced they can put that into a solid licence. However, they
explicitly decided not to, in order to push their idea of open software.
See http://www.gnu.org/licenses/gpl-faq.html#WhySomeGPLAndNotLGPL

What annoys me propably most is that this simple licence is non-GPL
compatible, and any software written with this licence is not allowed to be
linked against GPL-software:
   This code may be freely modified, copied and distributed, so
   long as no fee is charged for it.
(question 3, http://www.gnu.org/cgi-bin/license-quiz.cgi)


Secondly, a practical way may be:

As you surely are aware, it is possible to include an exception to the GPL,
stating you, as the copyright holder allow that your program links against
(specific) non-GPL-compatible libraries.

Now, if I read the answer to this FAQ:
http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat
The FSF states here:
    If you wrote and released the program under the GPL, and you
    designed it specifically to work with those facilities, people
    can take that as an implicit exception permitting them to link
    it with those facilities. But if that is what you intend, it
    is better to say so explicitly.
"those facilities" refer to a interpreter who automatically "binds to"
non-GPL-compatible software, like libraries.

Well, I do not see a technical difference from, for example the people who
designed netatalk to specifically work with the OpenSSL "facility", and a
linker who dynamically links with (binds to) the OpenSSL library.

So by explictly designing GPL code to link against non-GPL code, the author
*implicitly* gives the exception that the program may indeed be linked to
this particular non-GPL code.


Kind regards,
Freek Dijkstra