[Nagiosplug-devel] nagiosplug licensing is self-conflicting

[Andreas Ericsson]

Ton Voon wrote:
> 
> 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?
> 

Just write "License: See COPYING" or some such. That way you won't have 
to fiddle all the plugins if it ever changes in the future.

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

But the limitation works the other way around. OpenSSL haven't got 
claims on the plugin developers. The plugin developers have potential 
claims on the plugin users that they must include the SSL copyright 
exception and notices whenever re-distributing the code. Since the 
plugin developers can simply refrain from pressing charges it's not much 
of an issue (although if it can easily be fixed it should be).

> 
>>> 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
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________________
> Nagios Plugin Development Mailing List 
> Nagiosplug-devel at lists.sourceforge.net
> Unsubscribe at 
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
> 

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231