[Nagiosplug-devel] nagiosplug licensing is self-conflicting
Ton Voon
ton.voon at altinity.com
Tue Oct 18 02:20:29 CEST 2005
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
More information about the Devel
mailing list