[Nagiosplug-devel] nagiosplug licensing is self-conflicting
Andreas Ericsson
ae at op5.se
Mon Oct 17 14:36:43 CEST 2005
sean finney wrote:
> hi folks,
>
> something that recently came to my attention is that there are potential
> licensing conflicts within the nagios-plugins project.
>
> as nagios-plugins are a GPL'd project, that means they can not be compiled
> against 3rd party API's that do not meet the criteria of the GPL. the
> most noticable issue is regarding openssl, though there are perhaps others
> into which i would have to look more closely. i'll start with the
> former, because i have some experience dealing with it in other
> projects.
>
> === part 1 - openssl ===
>
> wrt openssl, it is unfortunately not compatible with the "stock" gpl
> on many distributions (including debian), because it is not considered
> "part of the operating system" and thus is a "derived work". The solution
> in this case is fairly straightforward. any of the following would
> be sufficient:
>
> - change the license to something that doesn't conflict (lgpl, bsd-style, etc)
> - modify the code to be able to use other ssl implementations (like
> gnutls), and leave it to the distributions that have the problem to
> choose the non-conflicting option.
> - put an addendum to the current copyright such that it is "GPL,
> but exception is made for linking against OpenSSL". this is what
> the folks at mysql have done, btw.
>
The last option is what the openssl team recommends. It also says:
"Some GPL software copyright holders claim that you infringe on their
rights if you use OpenSSL with their software on operating systems that
don't normally include OpenSSL."
The problem is thus not with openssl, but with the copyright holders of
other programs that may or may not link to openssl. If all the
developers and contributors are OK with using OpenSSL there is no problem.
IMO, this is really splitting hairs. OpenSSL is as available as any
GPL'd software. The reason for it not being GPL'd is that it isn't hard
to write a TSL library so if corporations were unable to use openssl
they would simply roll their own and withhold their clever solutions
from the open community (which is exactly why glibc is LGPL rather than
GPL, btw).
> peronally, i prefer the second option, but it's also the most work. for
> more information on this particular issue, here's some helpful
> information:
>
How incompatible are the two interfaces? Does everything have to be
changed? Perhaps we could use an abstraction layer on top the plugins to
move the problems to somewhere where users won't tinker with it?
> a crash-course into the problem:
>
> http://www.gnome.org/~markmc/openssl-and-the-gpl.html
>
> openssl project's recommendations:
>
> http://www.openssl.org/support/faq.html#LEGAL2
>
>
> === part 2 - other potential issues ===
>
> in addition to the openssl issue described above, i foresee potential
> problems with other plugins which make use of api's or command-line
> programs which are also not GPL-compatible.
Using command line tools that aren't GPL'd doesn't violate the GPL, just
as gcc, bison, yacc and flex can be used to compile and create
proprietary code and proprietary applications can be written in
PHP/Perl/Python/whatever.
> the only other two that
> immediately come to mind are lmstat and qmail (neither of which are GPL
> compatible but are used), but i haven't looked closely into ./contrib,
> where other problems are likely to exist.
>
> what to do about these is probably a touchier subject, and i'd
> appreciate any ideas that you folks might have.
>
Put a doc in the distribution highlighting the problems and make it
available to everyone who are likely to contribute code (a HACKING file
or some such). Make it plain that when they *do* contribute code it will
be under the GPL with this and that exception (for openssl, for instance).
lmstat and qmail coders aren't going to complain. If plugin developers
are having issues with this then they will simply stop submitting code,
most likely after having had a heated discussion on this list. It won't
be done quietly anyways.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
More information about the Devel
mailing list