[certi-devel] CERTI and external libraries

[Benoît Bréholée]

  [Note to non-subscribers: this is a mail sent to the certi-devel
  mailing-list and the Reply-To is set to the list, which is
  public and archived. If you reply to the list while you're
  not subscribed, expect a delay due to the moderation process.]


Since the first CERTI release as free software, there have been a few
propositions about the use of external libraries, usually to improve
portability. On the other hand, ONERA would rather have no dependency so
that users may install CERTI easily on Unix systems. I think both
options have legitimate motivations, so I'd like to propose a way to
reconcile them (since they appear to be incompatible at first look).
Here are some conditions a library should satisfy to be used from CERTI:

* The library should be widespread and of high quality.

* The library should be optional. The library may be used on platforms
having this library, but CERTI should still build and run correctly if
the library is not there. "Correctly" means everything HLA-related
should work. Optional features that are not directly related to the
implementation of the HLA API may depend on the library though.

* The library should be accessed through concepts (C++ classes) that
either exist or can be introduced in CERTI. These concepts should be
identified and associated with abstract classes, so as to have two
implementation subclasses for each of them: one using the library, and
another one using the current method. In other words: only abstract
classes and their subclasses, no #ifdefs. That may be a problem if the
concept to introduce really doesn't fit with CERTI's current design, or
requires too much significant changes. This is to be discussed on a case
by case basis.

Note that there are also legal conditions to use such libraries:

* The library should be GPL-compatible, because RTIG and RTIA are GPL.
Even if the library is used only by libCERTI, the RTIG and RTIA use
libCERTI, so everything linked has to be GPL-compatible. (see the list
of GPL-compatible licenses[1]).

* The library should not be GPL if it is used by libRTI. The libRTI is
LGPL so as to allow people to distribute both CERTI and proprietary
federates. If libRTI were GPL, that would be a legal problem for them.
So for the same reasons as libRTI itself, anything linked to libRTI
should be non-copyleft (eg. BSD) or soft-copyleft (eg. LGPL).

* The library should run at least on GNU/Linux, unless its purpose is
to solve portability issues. This is required by the Savannah hosting:
programs may run on non-free platforms, but have to run on at least one
free platform. So having significant features working only on some
non-free platform would not be acceptable for Savannah. And that
wouldn't be a good thing for the project as well. A free library running
only on a non-free platform but used for portability purposes would be fine.

So if you'd like to propose the use of a library, consider these
requirements, I think this is a way to comply with most needs.

This is a draft, I'd like to get points of view about the above
conditions. If you thought of the use of external libraries, your
opinion is welcome, whether it concerns the general approach or
particular cases.

[1]<URL:http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses>
-- 
Benoît Bréholée