Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hi thibault,
On Tue, Aug 30, 2005 at 10:58:31AM +0200, Thibault Genessay wrote:
> The problem is that it implies that some module of our proprietary=20
> system include headers from Nagios, and even though this module does not=
=20
> link with Nagios libs, I think the GPL forces it to be also GPL'd. Then,=
=20
yup.
> However, I have thought of a workaround but I did not see (or=20
> understood) what the GPL states about it. It is binary compatibility.=20
> Rather than including our system headers, the NEB could send data in an=
=20
> apparently unordered manner and our system get this data and=20
> automagically build the structures back from it. This avoids the NEB and=
=20
> the system to share any header file. This is the agressive solution that=
=20
> nobody would like, but is kinda legally possible. (even if it needs to=20
> be reworked by a jurist).
when on ambigiuos ground, your best bet is to clear it with the author
ahead of time. if you really want to get out of this issue, instead of
"an apparently undordered manner", i'd suggest encoding it a meaningful
but non-nagios-defined order (maybe XML), where you wouldn't need nagios
source code to reassemble it into a meaningful object, and would be
generally useful in its own right. or, as you're already doing, using
a db as a go-between.
> But if we want the apps to talk directly rather than through the DB, we=
=20
> need them to be open source which is not compatible with our businesses=
=20
> (after all, we are selling stuff, aren't we ?). The possibility I have=20
well, if your business is built around an open source application, i
don't have that much sympathy if you discover your percieved business
model doesn't match with the open source ethos/license
> I think this modification is strategic for the Nagios project because it=
=20
> would premit it to be shipped with important business applications that=
=20
> would otherwise use another basis. The community would benefit from a=20
> powerful way to externalize data from Nagios and it could eventually=20
> promote the way Nagios perform checks and report results to an=20
> industry-wide standard.
i remain to be convinced that changing the nagios license to allow
proprietary derivative works / modules will in any way benefit the users
of nagios. but then again, i'm not the author so maybe you'll have some
luck with ethan.
sean
--cWoXeonUoKmBZSoM
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)
iD8DBQFDFCe8ynjLPm522B0RAueCAJ9AiOILpx5PzAaMVyDvr1N1DML+wQCfSXDq
O5IsDdP8BTBeS6lnQrlQklc=
=ZfNk
-----END PGP SIGNATURE-----
--cWoXeonUoKmBZSoM--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]