Re: [Nagios-devel] Re: AW: Re: [Nagios-users] Nagios 3.0,natively windows codes,support mysql,support agentless monitor , new web interface,more,Greatly
Posted: Sun Aug 28, 2005 11:07 pm
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hey,
On Mon, Aug 29, 2005 at 01:18:41AM +0200, Andreas Ericsson wrote:
> >of course, this largely depends on whether or not you need to compile
> >them against nagios source/headers, whether or not the modules
> >are useful in their own right apart from nagios, and other factors
> >which could determine their status as "derived works" or not.
>=20
> Yes. This is actually pretty tricky. One of the modules I'm writing now=
=20
> uses a spooling mechanism for binary data to be distributed to several=20
> hosts. This spooling mechanism was originally proprietary, but if we=20
> have to make it GPL, then so be it. It's possible though that GPL'd code=
=20
> can be linked to proprietary code (rather than vice versa) which would=20
> be the case. This is what the lawyers are looking in to.
unfortunately you can't have gpl'd code link against non-gpl'd
code either. that would definitely fall under either the "modification"
category or "derivative work". this has been a major PITA in debian, becau=
se
there are a lot of good-intentioned software projects that license their
code under the GPL, but then link it against openssl libraries[1]. =20
this ties in pretty heavily to section 2b, with a bit of 4, and 6.
of course ianal, but from my dealings with the gpl, your best
bet is to change/clarify license terms with ethan to allow proprietary
modules if that's what you want. or just gpl the modules, which would
make everyone else happy
> >this is true, under the circumstance that you provide source code
> >along with the binary GPL'd software, or have otherwise provided
> >the information they need to locate the original source code (or
> >give an offer to provide said code). sections 1 and 2 only address how
> >you can handle the source code--section 3 clarifies for what you can do
> >with binary-only distribution.
>=20
> The stuff at oss.op5.se is source-code only, so that's ok then.
i was really referring to the final product that you distribute
to your customers.
anyway, i'll follow up with the rest in private...
sean
[1] there are some cases where you can get away with such linking, but
only if such libraries are considered part of the "core operating
system".
--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFDErQ+ynjLPm522B0RApQeAJ9C8g/FRo86fwVYB2qXC9j1hCCO3wCaA/AM
dn5pB41ShLDF/5bwI5fXOZI=
=ddZV
-----END PGP SIGNATURE-----
--jI8keyz6grp/JLjh--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hey,
On Mon, Aug 29, 2005 at 01:18:41AM +0200, Andreas Ericsson wrote:
> >of course, this largely depends on whether or not you need to compile
> >them against nagios source/headers, whether or not the modules
> >are useful in their own right apart from nagios, and other factors
> >which could determine their status as "derived works" or not.
>=20
> Yes. This is actually pretty tricky. One of the modules I'm writing now=
=20
> uses a spooling mechanism for binary data to be distributed to several=20
> hosts. This spooling mechanism was originally proprietary, but if we=20
> have to make it GPL, then so be it. It's possible though that GPL'd code=
=20
> can be linked to proprietary code (rather than vice versa) which would=20
> be the case. This is what the lawyers are looking in to.
unfortunately you can't have gpl'd code link against non-gpl'd
code either. that would definitely fall under either the "modification"
category or "derivative work". this has been a major PITA in debian, becau=
se
there are a lot of good-intentioned software projects that license their
code under the GPL, but then link it against openssl libraries[1]. =20
this ties in pretty heavily to section 2b, with a bit of 4, and 6.
of course ianal, but from my dealings with the gpl, your best
bet is to change/clarify license terms with ethan to allow proprietary
modules if that's what you want. or just gpl the modules, which would
make everyone else happy
> >this is true, under the circumstance that you provide source code
> >along with the binary GPL'd software, or have otherwise provided
> >the information they need to locate the original source code (or
> >give an offer to provide said code). sections 1 and 2 only address how
> >you can handle the source code--section 3 clarifies for what you can do
> >with binary-only distribution.
>=20
> The stuff at oss.op5.se is source-code only, so that's ok then.
i was really referring to the final product that you distribute
to your customers.
anyway, i'll follow up with the rest in private...
sean
[1] there are some cases where you can get away with such linking, but
only if such libraries are considered part of the "core operating
system".
--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFDErQ+ynjLPm522B0RApQeAJ9C8g/FRo86fwVYB2qXC9j1hCCO3wCaA/AM
dn5pB41ShLDF/5bwI5fXOZI=
=ddZV
-----END PGP SIGNATURE-----
--jI8keyz6grp/JLjh--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]