[Nagiosplug-devel] nagiosplug licensing is self-conflicting

[sean finney]

hi,

On Mon, Oct 17, 2005 at 03:53:03PM -0400, John P. Rouillard wrote:
> As I understand it, the programs can not be compiled and then
> distributed. So the binary RPM's/other distributions are a problem,
> but not the source RPM's. Do you agree?

i'll have to double check my notes, but i think you're right.  there could
potentially be a problem because it won't compile against any api
other than openssl's, but i'm not sure about this.

> The GPL programs are perl scripts calling the non-free components via
> fork/exec in this case correct? If so then it's not a problem
> AFAIK. See:
> 
>  http://www.gnu.org/licenses/gpl-faq.html#TOCGPLPluginsInNF
> 
>  http://www.gnu.org/licenses/gpl-faq.html#TOCMereAggregation

okay, then "mere aggregation" addresses that.  thanks for pointing
that out.  previously, everything i had seen dealt with the converse;
that is non-GPL programs calling GPL'd ones.

On Mon, Oct 17, 2005 at 11:32:17PM +0200, Andreas Ericsson wrote:
> >- 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.

yes.  it might be more straightforward in this case, but i think the
answer would then be to clarify the position as such.  however, it
can get really, really tricky when you start dealing with shared
libraries and api's.  

for example, say nagiosplug decided to release a shared library (GPL'd
of course), which was then used by other 3rd party software projects.
if any of these other 3rd party software projects were also GPL'd,
then they too would be inadvertently made in violation of their own
license because they would then be linking against openssl indirectly
through us.  it may sound farfetched for our particular situation,
but this happens a lot.  this was a major pita with mysql, because you
have pam/nss modules that link against mysql, which means effectively
the entire OS could link against it :(

> 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 

i think it's a bit more than splitting hairs.  it's not a major issue
because there are trivial ways to remedy it, but it's still a potential
license violation.  

> 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 believe the API's are similar, but not compatible (or at least not
completely so), though i haven't verified this for myself.  since
i've heard this come up a few times within debian-devel, i can
probably call upon some volunteers from there to send me an initial patch,
or at least some notes about differences.

but in any case, yes i think it should be abstracted away, and not just
because of this.  having recently dealt with some ssl-related bugs
in one plugin and still having a small number more, i'm beginning
to think this would be a good idea.  


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20051018/b0067eec/attachment.sig>