Congratulations on the AWS changes integration. I appreciate the license change for FreeRTOS and I am wondering how that will affect the FreeRTOS+ ecosystem. I’m particularly intested in CLI, FAT, Trace and IO. Thanks!

The website is being updated to document the new licenses. FreeRTOS+TCP, FreeRTOS+CLI and FreeRTOS+UDP are already under the MIT license in the FreeRTOS v10 download. +FAT can be made available under the MIT too but so far has not been re-released as it is in the labs download which has not yet been updated.

Great! Thank you very much.

On 14/12/17 20:59, Richard Barry wrote:

The website is being updated to document the new licenses. FreeRTOS+TCP, FreeRTOS+CLI and FreeRTOS+UDP are already under the MIT license in the FreeRTOS v10 download. +FAT can be made available under the MIT too but so far has not been re-released as it is in the labs download which has not yet been updated.

The real step up, as I see it, will be the TLS stuff under MIT license. People have been able to use FreeRTOS with LWIP for many years, and there are at least a couple of usable FAT implementations under commercial embedded-friendly open source licences. TLS has been the missing part – you have had to buy a licence (fine for some people and projects, less good for others) or switch to a completely different system like mbed.

The TLS library in the FreeRTOS kernel download (from SourceForge) is a third party product so we can’t change the license. The TLS in Amazon FreeRTOS (from GIT) is mbedTLS (Apache license) with a TLS abstraction layer on top.

Hi David,

People have been able to use FreeRTOS with LWIP for many years,

That is true but, FreeRTOS+TCP has several advantages above FreeRTOS & lwIP. Yes the combination worked but there were (I had) many complaints, mostly because lwIP was not written for a multi-tasking system. But also, lwIP is only fast (efficient) when you do NOT use BSD sockets. FreeRTOS+TCP only has a BSD socket interface which is totally optimised. In short: there were many good reasons to develop a proprietary UDP/TCP/IP library that is totally integrated with the FreeRTOS kernel. And better: FreeRTOS+TCP is already available under the liberal MIT license! ( actually, the FreeRTOS+TCP library has been tested by individuals at the MIT )

and there are at least a couple of usable FAT implementations under commercial embedded-friendly open source licences.

FreeRTOS+FAT will get an MIT license as soon as there is time to move it from /Labs to “mainstream”. The only comparable embedded-friendly FAT driver that I know of is ELM by ChaN. It is great code, more compact than +FAT. But the advantage of FreeRTOS+FAT is that it much easier to understand. Also its error-handling is very complete and helpful. It has stdio-like user-functions and it mounts several drives into a single root "/". For instance, a file like “/ram/settings.txt” can be handled by a RAM-disk driver.

TLS has been the missing part – you have had to buy a licence (fine for some people and projects, less good for others) or switch to a completely different system like mbed.

I totally agree with this statement. It would be nice to find a TLS library that has the same liberal license.

On 15/12/17 18:20, Hein Tibosch wrote:

Hi David,

People have been able to use FreeRTOS with LWIP for many years,

That is true but, FreeRTOS+TCP has several advantages above FreeRTOS & lwIP. Yes the combination worked but there were (I had) many complaints, mostly because lwIP was not written for a multi-tasking system. But also, lwIP is only fast (efficient) when you do NOT use BSD sockets. FreeRTOS+TCP only has a BSD socket interface which is totally optimised. In short: there were many good reasons to develop a proprietary UDP/TCP/IP library that is totally integrated with the FreeRTOS kernel.

Yes, I fully appreciate that. There can be many advantages in an integrated and dedicated network library as part of FreeRTOS.

And better: FreeRTOS+TCP is already available under the liberal MIT license! ( actually, the FreeRTOS+TCP library has been tested by individuals at the MIT )

and there are at least a couple of usable FAT implementations under commercial embedded-friendly open source licences.

FreeRTOS+FAT will get an MIT license as soon as there is time to move it from /Labs to “mainstream”. The only comparable embedded-friendly FAT driver that I know of is ELM by ChaN. It is great code, more compact than +FAT. But the advantage of FreeRTOS+FAT is that it much easier to understand. Also its error-handling is very complete and helpful. It has stdio-like user-functions and it mounts several drives into a single root "/". For instance, a file like “/ram/settings.txt” can be handled by a RAM-disk driver.

The ChaN code is the one I have used. I have no experience with the FreeRTOS code, so I can’t compare – but again I can see many advantages in having it as part of FreeRTOS rather than a third party generic library.

TLS has been the missing part – you have had to buy a licence (fine for some people and projects, less good for others) or switch to a completely different system like mbed.

I totally agree with this statement. It would be nice to find a TLS library that has the same liberal license.

As far as I can see, Amazon FreeRTOS /does/ include TLS under an MIT license. Anyway, this is all good stuff. I am always happy to see new features in FreeRTOS (the stream and message buffers are a fine idea), and happy that more features are available for more people and with less effort. I know there is always a certain risk when a small company or project enters close cooperation with a large company, but everything I have seen so far looks good, and I think it will be good for the future of FreeRTOS, the community of users, and the folks developing and supporting it. Now I just need to find a new project that will give me an excuse to play with the latest version!

Just a small correction – the TLS stack in Amazon FreeRTOS is third party and actually under the Apache license, rather than MIT.