[Nagiosplug-devel] nagiosplug licensing is self-conflicting

[Andreas Ericsson]

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