[riot-users] Need clarification on lgpl license terms for proprietary work
ludwig.ortmann at fu-berlin.de
Tue Sep 30 10:43:23 CEST 2014
Dear Shankar and RIOT Users,
The following is not legal advice, just the best interpretation of the
matter at hand that we as legal amateurs can come up with.
We are aware of the licensing issues and working on solutions.
You can help.
When we changed from GPL 3 to LGPL 2.1 we did this precisely to allow
proprietary applications. However, we were not (and are still not) experts
in licensing. Due to this, the choice turned out to be somewhat suboptimal.
What we would have really wanted was probably some GPL with a linking
exception. Also, our community is somewhat diverse on this topic and others
would have gone for an Apache license.
This being as it is, we don't want to change licenses every week until we
have found the ideal license, but are rather trying to come up with a more
sustainable alternative (see below).
However, we did and do want to support dynamic linking anyways, so
proprietary applications *will* be possible with an LGPL licensed RIOT.
# Using LGPL:
As far as we understand it, there are two approaches to being LGPL
- Add support for dynamic linking
- Verify binaries
## Dynamic Linking:
There has been some initial work on dynamic linking support you can use to
implement the missing pieces for the platform you want to use.
The support is currently not in master yet, but there's an open pull
## Verifiable Binaries
Kaspar Schleiser is working on a build system that will allow verification of
binaries. The idea is to enable the build system to take a proprietary .a
containing proprietary code and use it to create the final image.
If the same RIOT version + compile has been used, the resulting binary should
That way, by releasing the proprietary .a, anyone can prove that a specific
RIOT version has been used unaltered to create some proprietary firmware, thus
complying with LGPL.
# Sustainable licensing
As we discovered, open source licensing, especially for embedded software,
is far from trivial. Also, we expect that the legal aspects of the currently
existing licenses might change with changes in copyright law or advancements
in its interpretation. Therefore, we assume that we are unable to "solve"
the licensing problem just by choosing the "right" license.
We are currently exploring the implications and methods of creating a
non-profit organization that can act as legal entity to manage licensing.
The general idea is to add a "Contributers License Agreement" that will
grant this entity the right to relicense the works under any license that
fits our higher goals.
The higher goals are:
- RIOT itself should remain free software, any changes to it must be
contributed to the project
- it should be possible for developers to create proprietary applications on
top of RIOT
- it should be possible for users to update the firmware of devices built
# How you can help
There are several ways in which you as a RIOT user/developer can help with
solving the issues:
- add dynamic linking support for your target platform, see above
- help Kaspar with the verifiable static linking support
- communicate your needs, experiences and expectations
Last but not least, none of us intends to sue anyone for building
proprietary applications with RIOT as long as they are in line with our
goals (as given above). We embrace your contributions and will be happy to
help you in the task of getting them into RIOT as best we can. However, it
is possible for anyone, for example your competitors, to sue you for
copyright infringement if you build a proprietary application on top of RIOT
that does not comply with it's license terms.
Ludwig on behalf of the RIOT developers
On Thu, Sep 25, 2014 at 10:11:41AM +0530, Shankar Bandal wrote:
> We have query on license terms and conditions.
> We are planning to develop algorithms based on cm4 and we are planning to
> use RIOT.
> Based on our initial study about this os, it doesn't support dynamic
> loading of library, also we don't see make files which can generate dll
> (.so). Also final executable is single binary.
> Which means work/algorithms developed with RIOT will be considered as
> derived work and will need to open to all free of cost.
> But from RIOT website, proprietary work need not be open.
> So we need clarity on what precautions/steps we should follow to protect
> our work which involves our IPs
> Also static libraries which linked with RIOT to form final single
> executable is considered as independent work and lgpl license terms are not
> applicable to them.
> Please clarify.
> users mailing list
> users at riot-os.org
More information about the users