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).
-
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.
-
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.
-
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). -
Reach out to contributors in painful-to-lose code areas, asking them to weigh in and whether they’d be willing to re-license.
-
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).
-
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.
-
Change the contributing guidelines to point out the new terms. Point out in the LICENSE file that there is an ongoing transition.
-
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).
- 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.
