The license is currently LGPLv2.1

Studies such as this one show that small companies and start-ups are going to determine IoT. More than bigger companies, such small structures need to spread development and maintenance costs for the kernel and all the software that is not their core business. Our analysis is that this is more compatible with LGPL than with BSD/MIT.

We are of the opinion that, compared to BSD/MIT, LGPL will improve final user experience, security and privacy, by hindering device lock-down, favoring up-to-date, and field-upgradable code. We think this a more solid base to provide a consistent, compatible, secure-by-default standard system which developers can build upon to create trustworthy IoT applications, while not hindering business models based on closed source linked with RIOT (see the automated tools provided to help check LGPL compliance, and/or this technical guide)

Since solutions competing with RIOT are quasi-exclusively BSD/MIT, we gauge that LGPL is a way to stand out favorably, and is a characteristic backing positive comparisons of RIOT with Linux.

Last but not least, we think that (L)GPL is a better base than BSD/MIT to keep the community united in the mid and long run.

For the record: we have also considered MIT/BSD (see this thread), but there was not enthusiastic majority supporting such a switch.

Compare https://github.com/RIOT-OS/RIOT/issues/2128

In short there are certain Coding Conventions to follow and we are using Github’s pull requests for code review. So for new features and fixes create a fork of the RIOT repository and open a pull request with a detailed description of your changes.

For a more in depth description check out the dedicated document on development procedures.

Also, do check out the open community processes.

The Starter Guide might be just what you are looking for.

First of all, welcome to the RIOT community! There is a dedicated README on contributing listing opportunities to interact with fellow RIOT enthusiasts and some suggestions how to get started.

For critical vulnerabilities we would appreciate you to report them with a 90 day heads-up to security@riot-os.org first, before making them publicly available. You may use the GPG-Key 44C6AE441172F88D3423E81F5F7964D0F4239033 to encrypt your report.

It’s a very good idea to search our forum first, maybe someone has already solved your issue! You can also create an account there, and post via the forum website, or via email to help@riot-os.org following this guide. Another option is to log an issue in GitHub.

You’re also welcome to ask in the Matrix room #riot-os at matrix.org, but don’t be disappointed if everyone there is busy.

Check out this page on supported hardware. If your hardware is not listed there, you’re welcome to provide a port for your hardware!

This depends on the board and on the application. When you compile an application for a board, the last thing printed gives each sections memory footprint and looks like this:

    text       data     bss     dec     hex filename
    77732     296   24272  102300    18f9c applications/sixlowapp/bin/iot-lab_M3/sixlowapp.elf

The required RAM is data + bss, ROM is text + data.

Please note: Usually a big portion of RAM is consumed by the stack space for threads. Although RIOT maintainers try to optimize the default values, manual tweaking may be necessary to get the most efficient results. You can check the maximum stack usage at runtime with the shell command ps or the corresponding function thread_print_all() from the module ps.

See this page.

No. From the RIOT point of view the Raspberry PI is a supercomputer. RIOT targets mostly systems that are too constrained to run Linux (less than 1MB of RAM, no MMU). However, it is supported to run RIOT native on platforms like the Raspberry PI, and other hardware supported by Linux or BSD.

A good rule of thumb concerning RIOT support of a particular board is: can Linux support this board? If yes, then you should ask yourself why you really want to use RIOT (other than native) on this board. If no, then RIOT support is probably desirable.

There is not much to be gained from 64 bit support as RIOT does not target any other platforms that offer 64 bit. That being said there are pros and cons.

Pro:

• improve RIOT’s code base by fixing 64 bit related errors
• simplify toolchain setup for native

Con:

• effort / gain (as it’s unlikely we will support any other 64 bit platform, fixing potential 64 bit errors in RIOT is less beneficial)
• decreased 32 bit testing (unless we make 32 the default in which case the toolchain setup argument is diminished)

From our perspective this does not justify pulling manpower from other tasks. Nobody will stop you from adding support if you want to, though ;)

See also: https://github.com/RIOT-OS/RIOT/issues/6603

Please consider the following references for citation.

• Emmanuel Baccelli, Cenk Gündoğan, Oliver Hahm, Peter Kietzmann, Martine Lenders, Hauke Petersen, Kaspar Schleiser, Thomas C. Schmidt, Matthias Wählisch, RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT, IEEE Internet of Things Journal, Vol. 5, No. 6, pp. 4428-4440, December 2018.