ravendisplayed wrote on Thursday, December 14, 2017:
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!
rtel wrote on Thursday, December 14, 2017:
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.
davidbrown wrote on Friday, December 15, 2017:
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.
rtel wrote on Friday, December 15, 2017:
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.
heinbali01 wrote on Friday, December 15, 2017:
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.
davidbrown wrote on Monday, December 18, 2017:
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!
rtel wrote on Monday, December 18, 2017:
Just a small correction - the TLS stack in Amazon FreeRTOS is third
party and actually under the Apache license, rather than MIT.
Hi Richard and others.
I am in the process of evaluating FreeRTOS as the RTOS solution for opensourcesatellite.org
So far, it has proven pretty easy to get going, I have been very impressed by FreeRTOS by comparison to the support available from some expensive commercial vendors.
Anyhow, I have a question about the license on FreeRTOS+IO? From looking at the source code, it looks like this is GPL? However, the FreeRTOS website seems to suggest MIT?
Can someone clarify the licensing for the FreeRTOS+IO library?
It has also been available MIT licensed for the last few years - we need to put a link up to that too if it is not on the web. However the +IO product is deprecated really as we are starting to publish some new IO interfaces.