[Nagiosplug-devel] nagiosplug licensing is self-conflicting

[Ton Voon]

On 17 Oct 2005, at 22:32, Andreas Ericsson wrote:

> 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."

I would say the last option too because the OpenSSL team say it is okay.

I think that means we need to add an exception notice in check_http  
and check_ldaps (amongst others) within the help text. We should add  
something at a top level file as well - I will update the README with  
references to our licence and update some contact information.

There's a reference to GPL in the nagios-plugins.spec file, which  
looks like an RPM file. Can the line:

License: GPL

be changed to:

License: GPL, with exception for OpenSSL (see README)

without breaking anything?

> 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).
>

IMO, it is about respecting the various teams that we are taking  
advantage of.


>> 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?

I'm okay with the idea of using a different SSL library. An  
abstraction layer is a good idea, if there are major differences.

>> 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.

I don't think the GPL covers command line communication. There's this  
section in the GPL FAQ (http://www.gnu.org/licenses/gpl-faq.html):

"By contrast, pipes, sockets and command-line arguments are  
communication mechanisms normally used between two separate programs.  
So when they are used for communication, the modules normally are  
separate programs. But if the semantics of the communication are  
intimate enough, exchanging complex internal data structures, that  
too could be a basis to consider the two parts as combined into a  
larger program."

So I think command line invocation of external non-GPL programs are  
fine.

>>  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).

I'll add a text to the patches section of SF to say that all  
contributions are accepted only if they are GPL. Something I've been  
meaning to do for a long time.

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon