Licensing
Notwithstanding the individual nature of contributions, it shall be recognized that many individuals are some or other way sponsored by companies with their business interests. Companies’ support has in fact been vital in history of x-SER and companies depend on x-SER as much as x-SER depends on them. Preservation of this food-chain is thus of critical importance. Therefore in all possible decisions commercial interests shall be given a fair consideration.
An important role in avoiding conflicts is a clear delimitation of components that creates as a whole the x-SER. It is important that while a developer may be reluctant in accepting new contributions inside its components, he/she has to provide the interface to extend independently the x-SER functionality via another library or module.
Licensing requirements:
- the licensing shall ensure protection of developer interests. Additions or changes of licensing to a component have to be agreed by maintainer.
- new code to be integrated in the common TM and core have to be under the BSD license. Therefore the core will keep existing FhG/iptelorg GPL license as being the major contributor so far and new things from either party (or third party) will be BSD
- code that depends on other GPL code and exists now in the Kamailio (OpenSER) core will be integrated as library. Now, such code scope is sharing it by modules. See Design page for further understanding.
- there is no enforcement of re-licensing existing code – library, module and module’s API offer the mechanisms to add code under developer’s term
- new module or library contributions to the common project can be done as GPL or BSD, up to developer or sponsoring company
The licensing shall not be by any meaning a way to enforce aproval or denial of contribution. A contribution that does not follow maintainer constraints has to be updated to introduce an API that follows component’s restrictions in terms of licensing and use that to create the new component.