Need clarification on lgpl license terms for proprietary work

Hi,

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.

Regards, Shankar

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.

# Abstract We are aware of the licensing issues and working on solutions. You can help.

# Background: 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 compatible.

- 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 request: https://github.com/RIOT-OS/RIOT/pull/1421

## 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 MD5 match.

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   with RIOT

# 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.

Sincerely, Ludwig on behalf of the RIOT developers