Licensing discussion -- 2023 edition

Context and history

Discussions on revisiting the license of RIOT OS have been started around summer 2022 during the Friday maintainer meetings, based among other things on input received during FrOSCon and Chemnitzer Linuxtage. My original intention there was to check first with the maintainers whether moving RIOT from LGPL to any more permissive license would be an option – going forward only if there was wide enough consensus to ask the full community for a decision. Things got stalled for personal reasons, and given that the discussion is now flaring up also in the public chat, I’d rather have it in a structured way now already.

Rough proposed roadmap

This is a sequence of steps that all need to pass. If one does not, the others are moot, nothing changes, and the discussion is over (until someone proposes a different roadmap or the facts change).

  1. Propose that we could change to something less restrictive than LGPL. (This thread).

    At this point, no concrete license is proposed – any OSI approved license that is more permissive than LGPL is on the table. Please let’s defer discussions on the precise license to go with, unless a concrete outcome of a step until that question is reopened depends on the license chosen in step 6. Nobody is asked to commit to anything until then anyway, and I’d like to avoid hours of discussions that only few people care about if there’s an earlier show blocker.

  2. Ask current and major previous contributors about whether they’re willing to relicense their earlier contribution under a more permissive license.

    This is the main making-up-our-mind process, into which the arguments below will go.

  3. From a tentative list of people and organizations willing to relicense, look at how much of RIOT would stay with LGPL.

    For a good approximation, I’d go with looking at the output of git blame. That is not precisely copyright (a change might not qualify as copyrightable, or a later change on copyrightable code might overshadow the original contribution), but neither is any other technical tool we have, so I think it’s a sufficiently good approximation, because any non-trivial contribution is very likely to span more lines than are simply overshadowed later, and this it’s rather erring on the side of caution. As always, if there is major disagreement on this point, things stop here (because nobody around has the time and legal expertise to make manual case-by-case decisions).

  4. Reach out to contributors in painful-to-lose code areas, asking them to weigh in and whether they’d be willing to re-license.

  5. As a community (probably at a (V)MA/GA), decide whether what we’d lose if we went with the change is still worth it.

    Note that the code could still live somewhere in the organization, but it might be moved to packages (but that’s a separate discussion to be had along the way).

  6. Decide on a suitable replacement license. Popular options are Apache-2.0, MPL, and anything BSD-ish, as well as combinations thereof (For example, much embedded Rust code is “MIT or Apache-2.0”).

    This step can start already at step 4 or 5, but I don’t see much value in going through it as long as we’re not past at least a few other Go/No-Go points.

  7. Change the contributing guidelines to point out the new terms. Point out in the LICENSE file that there is an ongoing transition.

  8. Add a document to the tree in which people state their agreement to relicense their RIOT OS contributions to the particular license.

(It may make sense to start that document early, so that people who are pinged for this and don’t really care can just add their name and be done with it).

  1. Move code that still has contributions from people not on the list to an LGPL subdirectory / package / … (details to be decided along the way). Clarify in LICENSE what applies where. Add a note to all currently open PRs by people not on the list to avoid merges that misrepresent the contributor’s intention.

Some arguments that were had

(Yes that’s mainly my PoV … I trust the thread will bring up more!)

  • “Companies won’t touch LGPL”.

    It’s obviously not that easy – many do, and many can be convinced to do by someone familiar with all the details. Others have strict policies and thus don’t allow employees to even try it out on company time.

  • Companies that won’t touch an LGPL licensed RIOT won’t contribute back to a permissively licensed RIOT.

    I think this is questionable. The number of contributions to Zephyr by large companies that don’t contribute to RIOT indicates that there is willingness to contribute back.

  • Companies are forced by LGPL to contribute back.

    This is not what LGPL does. All they have to do is offer source code to their users. Even when they consider the owners of the devices as “users” (many do not these days, as devices are sold with a service, and the company itself is the user – which is what AGPL was created for), they only have to provide code to their users on request. I haven’t seen a single case where someone extracted patches from a shipped CD (or mail ordered source code – they’d be allowed to do that) and made a PR to RIOT.

  • Companies are forced by LGPL to allow their users to update the system.

    This is not what LGPL does. Only GPL3+ and AGPL contain that “tivoization” clause.

  • Opinions about companies.

    Paraphrasing visitors from community events: “I’m getting started with embedded, but I later want to work there. Companies won’t pick RIOT due to LGPL, and I want to start with something right away that I can also use for my CV”. (See the “convincing” part above: A senior engineer can probably explain why RIOT under LGPL can be used by them, as can an external consultant. A new hire likely does not have the confidence and/or standing to have that discussion.)

  • We have the bindist option.

    Yes. That’s also barely maintained, is a hassle to use (for reproducability you need to publish your full build container), and doesn’t fly with non-C languages or even C with LTO – for example, the current Rust code transpiles C to Rust (creating a derivative work) and compiles that in with all the rest of the user code.

  • LGPL is an important part of our message to the community that we are the Libre option.

    It’s part of a message, but we’re currently not sending this message – we still have nonfree programmers by default on some boards, and users can pull in nonfree components (such as the ESP32 SDK) without any notice. If we wanted to send that message, we could do it no matter the license. But LGPL doesn’t make us any better denizens of the FLOSS world, and doesn’t give the users any assurances on the future of the project.

    This is related to the implied promise that RIOT won’t just go and start being published as BSL or anything else nonfree in the next release. I claim that that, too, is unrelated to LGPL: If there were an entity that could decide that RIOT pulls a 180 (say, start selling RIOT as a platform-as-a-service thing), they could do that just as well if they use the bindist mechanism and start adding any new modules under their new license. All the LGPL would do is that anything they fix in the existing modules would stay available for the Libre-RIOT fork that would promptly ensue – but given how those projects diverge, that will be useful for a few months at most, and they could be as hostile about is as they like (eg. run all the old code through an indentation tool, and publish their source on CDs without any commit history), so the practical value would be limited. What prevents such a scenario is our community governance, not the LGPL.

  • There’s really a lot of people that’ll need to sign this off.

    Yes there are, but much of the code was done by few, and many contributors were employed by larger organizations (HAW, FU Berlin, INRIA, and probably one or more I’ve missed) who hold sufficient rights to their employees’ or students’ contributions that a statement from representatives suffices to tick many boxes at once.

    Quoting my earlier Matrix messages:

    To get some very quick numbers (commits rather than lines): If I assume that all currently active devs give their OK (because if not, there will be no relicensing anyway), and all currently active organizations, that gets us to 75%. Add Gunar, Joakim, Sebastian, KyYc0o, Thomas Eichinger, Dylad: : 85%. 10 more, 90%. And that’s even though I’ve missed quite a few mail aliases all over. Those 75% in commits, mapping to lines of C code, correspond to 65% LoC in sys and core, but there it’s less than 20 developers until we get to 95% LoC coverage.

    It’s all rough numbers because I don’t have good methodology yet and it’s all just hacking around in .mailmap, but I think it shows the direction.

    My guess is that if there is a broad consensus in the community to go this way, and add maybe sprinkle in a few function rewrites, we might lose a few boards that have long not been maintained, a few drivers, but nothing essential. (If we don’t have a broad consensus, this stops at 2. way before attribution of modules becomes relevant).

  • LGPL was the right choice 10y ago. What changed?

    Back then the project didn’t know what’d happen if commercial users were faced with the decision to use RIOT under LGPL terms or not use it at all. mbed has shown that organizations of a sufficient size would contribute to a permissively licensed OS but implement it on their own (even publicly) if they’re not happy with the license terms. Back around 2013 there were no competing FLOSS RTOS – there was contiki, but its fragmented nature (barely any upstreaming) made it a non-option for many users in the first place. Now that there are mbed, Zephyr and RIOT, commercial users don’t even need to do that, because they have alternatives they didn’t have back then. They may be less universally usable, but the width of RIOT’s device support is more relevant to hobbyist than commercial developers, so its main benefit is not pulling too many users from that area.

    Also, we have seen that even companies generally understand the value in having upstream software, and contribute to permissively licensed projects just the same as they do to LGPL licensed projects – provided they use the latter in the first place.

Regarding the choice of licensing for RIOT OS, I believe it’s essential to consider the composition of the project’s contributors and their legal backgrounds. RIOT OS primarily involves contributors from Germany, France, and other Northern European countries. Given this mix, it’s worth exploring licensing options that align with the legal traditions in these regions.

In terms of legal traditions, many of the contributors come from countries with a civil law legal system, which differs significantly from the common law system found in the United States. The civil law tradition places strong emphasis on protecting an author’s moral rights, including the right to paternity (attribution) and the right to the integrity of the work. It is crucial to choose a license that respects and preserves these moral rights, which are deeply ingrained in civil law systems.

Furthermore, having jurisdiction in Europe, rather than the United States, could be advantageous for resolving potential legal issues. It ensures that legal proceedings take place under the legal framework and cultural context more familiar to the contributors. This can be particularly beneficial when addressing matters related to moral rights.

The comparison to Linux is noteworthy. Linux, released under the GPL, has seen significant contributions and adoption from large companies, including those with strict open source policies. The license’s “copyleft” nature doesn’t deter these contributions. In contrast, RIOT OS’s adoption might be more influenced by its academic and quality-oriented aspects rather than the license itself.

Transitioning to a less restrictive license may raise concerns related to ‘tivoization,’ a concept of particular significance within the realm of free software. Tivoization entails a situation where parties can modify and utilize the software without being obliged to share those modifications with the community, thus potentially undermining the principles of free software collaboration and the community’s control over the project.

It’s worth noting that RIOT OS falls under the category of free software, not just open source. This distinction is pertinent, as exemplified by Apple’s approach in contributing to free software projects such as CUPS and KHTML, where their contributions sometimes occurred in a manner that did not fully align with conventional community-driven development practices, but rather as a legal necessity.

Furthermore, we can draw insights from the Zephyr project, which, in my view, grapples with challenges stemming from the practices of ‘corporate open source’ contributors. These contributors tend to employ an abundance of intricate macros that can be challenging to follow, potentially affecting the project’s accessibility and maintainability.

Given my personal preference, I would advocate for the CeCILL-C license, especially because it originates from INRIA, a major contributor to the project. CeCILL-C is tailored to be compatible with the French legal system, which has similarities with the civil law systems in Northern Europe. It reflects the legal traditions of the contributors and provides a license that respects moral rights while promoting free software contribution.

In my case, the choice of a free software license, the quality and the readability of the code, as well as the project’s academic aspects, have been determining factors in my decision to participate in this project. Furthermore, I am steadfast in my refusal to have my modest contributions relicensed under a permissive license such as BSD or Expat. In the event of such a change, I would be inclined to switch to a fork of the project that adheres to the principles of free software, alongside contributors who share this viewpoint.

In conclusion, it’s crucial to choose a licensing approach that aligns with the legal traditions of the project’s major contributors and ensures the preservation of moral rights, especially in civil law systems. While the choice of license is important, it’s also essential to focus on the academic and quality-driven aspects of RIOT OS, which can significantly influence its adoption and success.

Linux seeing significant contributions from large companies

Linux, unlike RIOT, has separation between user space and kernel space, and programs are created in such a way that the license of the kernel (or even the libc) do not make requirements on the way programs built on it are distributed.

If programs could be built on a RIOT OS kernel with the same effort they’d also need to distribute their Linux based programs, chances are things would be easier on them.


The LGPL in the version used here does nothing to prevent tivoization. While the topic on its own is interesting, I think it has no bearing on the discussion outcome because none of the options being discussed so far would change that tivoization of RIOT is allowed.

AIU, CeCILL-C does not prevent tivoization either, as it makes no mention of the authorization keys that are crucial to GPL3’s anti-tivoization cause.

Last but not least, unhappy as I am about that, any change in license that would make RIOT untivoizable would likely not be supported by some existing contributors, so attempting to change that is on a path to a stalemate and thus something I’d like to avoid.

free software, not just open source

I disagree with where you draw the distinction (pointing both at at FSF’s and FSFE’s recognition of permissive licenses as free licenses, and the topic of being “the Libre option” in the original post), but I’ll leave it at that, for it hopefully has no impact on the decision finding process we’re on here.

These contributors tend to employ an abundance of intricate macros that can be challenging to follow, potentially affecting the project’s accessibility and maintainability.

We have our share of intricate macros here already. I’d hope that we can solve this on the level of coding guidelines and review, rather than by keeping away contributors with different code style upbringings.

because it originates from INRIA

My current impression of INRIA policies is that they’re more leaning toward permissive than copyleft licenses these days. @emmanuelsearch, could you weigh in here?

CeCILL-C […] steadfast in my refusal to have my modest contributions relicensed under a permissive license

Switching to a different copyleft license is not what I had in mind with this thread, but I wouldn’t place it completely out-of-scope as long as it scratches the itches we have with LGPL. (A different copyleft license, MPL, was brought up by @oleg some time ago and I didn’t respond to that so far). To test whether it does, could you help me with some practical implications of CeCILL-C? (I can read the text, but as it’s not as simple a license as the BSDs and my legalese is not too great, I’d rely on the commentary, which for the GPLs I have a workable understanding of, but not here yet).

  • If RIOT itself were CeCILL-C licensed, would a downstream need to demonstrate that the software they provide was built from RIOT sources, and provide a way to rebuild their image with any additionally modified RIOT?

    (This is a requirement that is understood to follow from LGPL, and due to which we have our bindist process, which is both cumbersome and doesn’t give any practically usable results).

  • How is “effective access” to be understood?

I did not expect this direction of discussion, but hey, that’s what discussions are for. If CeCILL-C is a compromise we can rally the community behind, and it solves the issues due to which .

Hey there!

Here some (mostly unstructured) thoughts from my side for this topic:

First of all, I’m not (yet?) convinced of a license change and I still consider LGPL a good choice. Why?

Mostly for two reasons: 1.) I don’t think that changing the license would make a huge difference for the project. I don’t expect many more contributors because of a permissive license. Many more users? Maybe, but we do not even have any clue about the numbers of RIOT users right now.

I any case, the question where we would be with a different license or what we could gain from a license change is pretty much crystal ball gazing. Probably everyone has their assumptions or we can gather some feedback from companies, but in the end we’ll never know.

My guess is that (as @chrysn stated above) companies shying away from copyleft licenses would likely also not contribute back to an open source project under a permissive license. I also assume (as @kaspar stated some years back) that a commercial developer is more likely to make a decision based on technical arguments than on the license. I.e., if RIOT has features that makes it a superior choice any (serious) commercial user will probably accept the license. (Of course, the license is most likely a factor if potential contenders are en par from the technical point of view.)

2.) I consider RIOT’s current license as a unique selling point - or at least as something which distinguishes us from other projects.

What many companies do with their software projects under permissive licenses could (in my perspective) be called open-source-washing. It’s labeled open source and yes, maybe technically the license is accepted as a free software license, but in the end the resulting products cannot really be considered free and open.

Yes, @chrysn, I agree that there are probably more important things we would need to address in the community to make RIOT more FLOSSy but then let’s rather tackle these tasks instead of saying “Ah, we’re not a real FLOSS project anyway so the license doesn’t matter anyway.”

In my perception, our license makes RIOT stand out and reflect the spirit of the project and community - even if the technical and/or legal implications are negligible.

All that being said: if the community consensus would be in favor of a license change, I would not veto (not sure if I even have the power of veto) but one would still have to convince me of the benefits from a license change in order to make me agree on it.

Cheers Oleg

P.S. Originally, James Munns brought up MPL. My understanding of this license is very limited. It seems to be somewhat aligned with our goals even though its protection mechanisms seem to be quite weak.

Then again, I don’t really think that our current license provides a reliable protection against people with bad intentions with respect to our IP - it’s merely a statement we’re making.

P.P.S. Regarding CeCILL-C: I don’t really know this license and its implications but I would be very careful with licenses off the beaten track.

P.P.P.S. @maribu recently has summed it up perfectly in Matrix: in the end, our goal with the license is to protect our code from being integrated into some proprietary products without publishing the mandatory changes to our code. If someone wants to build their own business logic on top of it we’re perfectly fine and if someone would like to enrich our code base with their own proprietary device driver we would (grudgingly) tolerate it.

Unfortunately, none of the established licenses can guarantee exactly this (without any hard-to-grasp restrictions or cumbersome processes). Since designing our own license is hardly recommendable LGPL seems to be the closest fit so far.

– printk(“you lose buddy boy…\n”); linux-2.6.6/arch/sparc/kernel/traps.c

Is that license end goal still valid? And, does the current license provide that protection? And, are we still OK with the necessary trade-offs?

IMO, more than ten years in, RIOT could use some more adoption. RIOT does mostly fine from a technical perspective. Now more users, more use, more feedback would be great. We know for a fact that LGPL drives away users. Changing RIOT’s license to a more permissive one might change the balance from protection to more adoption, giving RIOT the exposure it needs to truly mature.

1 Like

exotic or in general uncommon licenses do not help to increase adoption, in particular in the commercial world. if you want to convince the law department, you better use one of the few licenses they know.

furthermore, licenses that are hard to comprehend are also a hindrance. for example, “I can read the text, but as it’s not as simple a license as the BSDs” doesn’t seem to be a good starting point.

in other words, if you have to spend time to explain your license, either because it is too complicated or rather unknown, you do not achieve your goal of being approachable.

1 Like

I would also warn about uncommon licenses.

Based on numerous discussions (this edition, and others) the choice of license is clearly expected to influence metrics in multiple dimensions: protection, contributions and adoption – maybe other dimensions too.

From what I gather, we are not having this discussion because of concerns with the above first two dimensions. I assume there is consensus that the code is quite well protected as it is, and 3-digit numbers of unmerged PRs indicate contributions keep coming at a rather unmanageable rate :grinning:

So it’s about something else – adoption.

Here, I agree. Due to NDAs and whatnot, we only know of the tip of the iceberg. That said, if this iceberg was gigantic and/or exponentially growing, we’d perceive different signals. Independently of absolute values and exact numbers, crucial questions include :

  • are the current size & growth sustainable in the mid- and long-term?
  • if not, would a more permissive license be worth a shot to foster a better protection/contributions/adoption tradeoff ?
  • if not, what’s our strategy?

So while I also truly love and adhere to the healthy principles of LGPL, arguments merely highlighting the advantages of LGPL (e.g. in terms of protection and philosophy) miss the point in my opinion.

Instead, we need strategy. Changing the license could be strategic. Just “no license change” is no strategy at this stage.

1 Like

I just want to say that it is not the specific license that makes Zephyr popular among big companies. It is rather the patent situation, and the cross-licensing of patents that makes it attractive. The companies involved know that they are significantly reduced risk of litigation from other companies involved. In addition, the decision making process is pay to play. (Many of the companies wish they could get that for the Linux kernel)

My experience is that more permissive licensed projects create far more private forks which diverge. It’s not the license itself that is the problem, it’s that managers have higher priority things to do than deal with technical debt due to lack of upstream patches.

I think what makes Zephyr most attractive is that it gets first party hardware support from vendors themselves as well as full-time maintainers through the Linux foundation.

The licencing might have been a necessity to make this possible, but this is not something we could pull off even with a licence change.

1 Like

For me, Zephir’s popularity has more to do with political, technical and historical aspects than with its license. For example, its “Getting Started Guide” supports Ubuntu, MacOS and Windows, whereas Riot’s “Native development on Windows and macOS machines is not officially supported”. With that alone, we’re losing half the people (not the best half, in my opinion…). Zephyr comes from the major US embedded systems company Wind River Systems and has been placed under the aegis of the Linux Foundation, also an American organization. This is what makes Zephyr so popular with large companies, much more than its license…

1 Like