Why LGPL and not GPL [9]? – About Licence

About license

This text is written to apply to OpenMHP library [1]. Further, OpenMHP library is defined to cover the classes required for MHP-compliant implementation and the description of the Adaptation Layer [2] used by those classes.

This text does not apply to any Adaptation Layer. Current work on Adaptation Layers is covered by separate descriptions and licenses.


This library is distributed under GNU Lesser General Public License (‘LGPL’), version 2.1.

LGPL is available in the OpenMHP distribution package, separately on OpenMHP project website [3], or from Free Software Foundation [4] [5].

For us to consider modifications to be incorporated into the version distributed by Axel Technologies, the author of the modifications must assign copyright of the modifications to Axel Technologies. This can be done by registering [6] on the OpenMHP website as a developer, then submitting modifications to Axel Technologies via email [7], via the developer forum [8] (posting to which is restricted to registered developers), or via other means available (including traditional mail).

Why LGPL and not GPL [9]?

OpenMHP is a Free implementation of MHP classes. As proprietary implemetations exist and are available for fee, developers of free software do not gain anything by not allowing use of OpenMHP in a proprietary software project. Rather, adaptation by vendors of eg. proprietary Set Top Boxes would have positive effects:
1) added resources in development, testing and documenting
2) high compatibility between Free and propriatery platforms

High compatibility would ensure that an MHP application would behave the same way on both proprietary and Free platforms. As proprietary platforms are widely available, vendors of proprietary platforms are likely to consider MHP applications that run well on their platforms as “compliant”, so any problems – even workarounds for bugs in proprietary MHP implementations – would have to be worked around by the developers of Free MHP implementation.

Also, developers of Free implementation are less likely to have resources to manage compliance certification, while adaptation of OpenMHP in proprietary platform would likely result in the vendor of that platform certifying a specific version of OpenMHP for MHP compliance. This would greatly benefit the developers of Free MHP platforms.

Thus, we believe allowing linking to non-Free software OpenMHP becomes more attractive to vendors of proprietary platforms who are then more likely to devote resources into improving OpenMHP, where not allowing that wouldn’t gain any new benefits.

Other reasons include that, at least in the beginning, there are likely to be requirements in linking to non-GPL components. While java.* and javax.* classes are definitely allowed to link to by GPL (section 3 [10]), some other components used might not fall to within the “system libraries” clause. Moving from LGPL to GPL might be considered when all such dependencies have been resolved by writing required java classes within the project, or if good components compatible with GPL are found. Still, even in such case linking via Adaptation Layer Interface should be allowed as a right additional to those conveyed by GPL.

Note that distribution of OpenMHP library must not include external dependencies, which have to be distributed in accordance to their respective licenses.


The primary goal of OpenMHP project is to produce an MHP compliant implementation of classes required by MHP specification.

To succeed in this goal, suitable Adaptation Layer must also be developed for interacting with the operating system. Adaptation Layers, by their very nature, are dependant on facilities provided by the platform, and thus separate Adaptation Layers for different platforms may need to be written, or specific Adaptation Layer to be adapted to another platform.

For this end, first Adaptation Layer already partially developed by Axel Technologies is also released. Note that this is software separate from the OpenMHP library, governed by separate license (which, in this case just happens to be LGPL as well), used by OpenMHP library via Adaptation Layer Interface to provide suitable insulation between the two. At this early stage, Adaptation Layer Interface hasn’t been well defined and code will be moved between OpenMHP library and Adaptation Layer as the interface specification goes further.

Later on, it is likely that other Adaptation Layers are developed, or the existing Adaptation Layer adapted onto different platforms. Also, dependencies on non-Free components should be removed from the Adaptation Layer, replaced by Free components or new code to implement the functionality currently provided by external components.

Development of solid Adaptation Layer Interface is required for easy porting onto different platforms, and is thus be considered a task of high priority. While changes in the interface are likely to happen in the future, it’d be best if such changes would be few and minimal, but at this stage the interface must be considered work in progress.

[1] http://www.openmhp.org/
[2] http://www.openmhp.org/
[3] http://www.openmhp.org/licenses/lgpl.txt
[4] http://www.fsf.org/
[5] http://www.fsf.org/licenses/lgpl.txt
[6] http://www.openmhp.org/forum/profile.php?mode=register
[8] http://www.openmhp.org/forum/
[9] http://www.fsf.org/licenses/gpl.txt
[10] Quote from GNU GPL Section 3: “However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.”

Contributing to the project

What to do?

You can participate to the OpenMHP project in many different levels. You can download the binaries and then give us feedback about the bugs, features and such things. Or you can download the source code and make the bug fixes yourself. If you like, you can then send the fixes to the project maintainer, who will then review your code. If your code is acceptable, it will be then added to the next release of the OpenMHP.

There are hundreds of functionalities that are not yet implemented in the OpenMHP code. Some of the functionalities are listed, some are not. You can choose your favourite topic and start to implement it. It is a good idea to ask from the OpenMHP forum, if someone is already implementing the same thing. If you are the first one to implement a certain functionality, your solution is working and is planned nicely, it will be added to the next release of the OpenMHP.

The software architecture is also open for discussion. If you think you have a good idea for the architecture, send your solutions to a project maintainer or to the forum. Your ideas will then get reviewed by professionals, and will get seriously concerned when the future changes to the system designs are discussed.

How to submit code to the OpenMHP project?

You can send your code submissions to 


The modifications to be incorporated into the version distributed by the OpenMHP project, the author of the modifications must assign copyrights of the modifications to the OpenMHP project.