FreeRTOS is not open source (again)

[Paul Sokolovsky]

Hello,

About a year ago (maybe a bit more), when esp-open-rtos project only
started, I expressed concern of the FreeRTOS choice. As there're a lot
of communication, I can't immediately find references to that - it could
have been a personal mail to Angus, or an email on this list, or
esp8266-re, or on some ticket on github. But I hope Angus remembers it
well, because the concerns raised were that FreeRTOS contains arbitrary
restrictions in its license, which is not compatible with Open Source
definition. What's more, the license which FreeRTOS maims in such way
is GPL, which is supposed to protect Free Software users rights with
better diligence than a typical "liberal" Open Source license.

So, FreeRTOS, a GPL-licensed project which isn't open-source. Calling
such situation "ironical" would be underestimation. Perhaps an
overestimation would be call it a spit in the face of the whole Open
Source and Free Software communities. And one would question motives,
and the presence of feeling of the responsibility before community,
of someone who selects FreeRTOS for use in a real Open Source project.
Those were concerns raised to Angus.

I'm happy to report that the above is not my hallucination and number
of people share the same concern about FreeRTOS:
https://news.ycombinator.com/item?id=12272507 . That's subthread of
discussion of Google's Fuchsia OS on HN, and that link possibly
didn't capture all FreeRTOS-related discussion, full discussion is at:
https://news.ycombinator.com/item?id=12271354

So, for your kind information and as an input for making due diligence
checks and decisions in the future. You may also want to check whether
your Code of Conduct contains clauses along the lines of: "We,
the project maintainers, undertake to perform all the decision, due
diligence, and action process to uphold Open Source nature of this
project and wider Open Source community in general, and to make all
efforts to avoid deterioration of Open Source community,
principles, and values due to the work on this project, or connected
with how this project is being used."


--
Best regards,
Paul mailto:pmi...@gmail.com

[Angus Gratton]

Hi Paul,

On Thu, Aug 18, 2016 at 03:22:33AM +0300, Paul Sokolovsky wrote:
> About a year ago (maybe a bit more), when esp-open-rtos project only
> started, I expressed concern of the FreeRTOS choice. As there're a lot
> of communication, I can't immediately find references to that - it could
> have been a personal mail to Angus, or an email on this list, or
> esp8266-re, or on some ticket on github. But I hope Angus remembers it
> well, because the concerns raised were that FreeRTOS contains arbitrary
> restrictions in its license, which is not compatible with Open Source
> definition. What's more, the license which FreeRTOS maims in such way
> is GPL, which is supposed to protect Free Software users rights with
> better diligence than a typical "liberal" Open Source license.

You brought it up on this Github issue about open sourcing the startup code (a task which is now largely completed, yay!)
https://github.com/SuperHouse/esp-open-rtos/issues/2#issuecomment-109734411

I fundamentally agreed with you then, and I fundamentally agree with you now. I'm happy that some commenters on Hacker News also share this view. I'm not sure how this changes anything pertaining to esp-open-rtos.

The choice to build esp-open-rtos around FreeRTOS did not hinge on FreeRTOS specifically. It was a choice to build an open source friendly RTOS environment using Espressif's MIT Licensed RTOS SDK release. To date these SDK releases from Espressif (RTOS 0.9.9 and earlier) are the only ones that incorporate an OSI-approved license, for the parts which are copyrighted by Espressif.

This means that reverse engineered copies of the binary libraries can immediately be BSD Licensed despite being derivative works. There's no need to prove clean room reverse engineering took place (which is very helpful, because proving this is very hard - doubly so in the context of community contributed code).

As I mentioned on the github issue, the BSD licensed reverse engineered parts can be incorporated anywhere and put under any OSI-approved license. It would be fantastic if these libraries could be made RTOS-agnostic or ported to another OS. I was interested in Contiki back then, there are probably even more interesting options now.

This is not yet possible without binary-level hacks, but we're an awful lot closer than we were in June 2015. To date the esp-open-rtos project contains the largest available quantity of usable open source licensed (OSI-approved) low-level system source code[*] for ESP8266 and we should feel proud of this achievement.

In the future, if someone (maybe you) takes that code and ports the remaining binary library FreeRTOS dependencies to a new RTOS platform then I'll be delighted.

Would it be possible to base an esp-open-rtos around an Espressif MIT Licensed SDK release? Of course, but if you want RTOS primitives then you still have all of the problems with reverse engineering binary libraries - either still with FreeRTOS or with an implementation where you don't have source code to read for the internals. If you succeed then at the end you're left with something which still isn't under an OSI-approved license and isn't legally any more open source than FreeRTOS is.

> So, for your kind information and as an input for making due diligence
> checks and decisions in the future. You may also want to check whether
> your Code of Conduct contains clauses along the lines of: "We,
> the project maintainers, undertake to perform all the decision, due
> diligence, and action process to uphold Open Source nature of this
> project and wider Open Source community in general, and to make all
> efforts to avoid deterioration of Open Source community,
> principles, and values due to the work on this project, or connected
> with how this project is being used."

The purpose of the code of conduct is to ensure people feel welcome to suggest contributions and be involved in the project without fear of being harassed or abused, and to make it clear that harassing or abusive behaviour will not be tolerated.


Angus

[*] ESP8266 Arduino probably has the most open source driver-level and above source code written for ESP8266, which is also a very impressive achievement.

[Paul Sokolovsky]

Hello,

On Thu, 18 Aug 2016 11:15:30 +0800
Angus Gratton <g...@projectgus.com> wrote:

> Hi Paul,
>
> On Thu, Aug 18, 2016 at 03:22:33AM +0300, Paul Sokolovsky wrote:
> > About a year ago (maybe a bit more), when esp-open-rtos project only
> > started, I expressed concern of the FreeRTOS choice. As there're a
> > lot of communication, I can't immediately find references to that -
> > it could have been a personal mail to Angus, or an email on this
> > list, or esp8266-re, or on some ticket on github. But I hope Angus
> > remembers it well, because the concerns raised were that FreeRTOS
> > contains arbitrary restrictions in its license, which is not
> > compatible with Open Source definition. What's more, the license
> > which FreeRTOS maims in such way is GPL, which is supposed to
> > protect Free Software users rights with better diligence than a
> > typical "liberal" Open Source license.
>
> You brought it up on this Github issue about open sourcing the
> startup code (a task which is now largely completed, yay!)
> https://github.com/SuperHouse/esp-open-rtos/issues/2#issuecomment-109734411

Thanks for the reference.

> I fundamentally agreed with you then, and I fundamentally agree with
> you now. I'm happy that some commenters on Hacker News also share
> this view. I'm not sure how this changes anything pertaining to
> esp-open-rtos.

It doesn't change anything now, but it could have changed when it
was first brought. It also something to think about in future cases.

> The choice to build esp-open-rtos around FreeRTOS did not hinge on
> FreeRTOS specifically. It was a choice to build an open source
> friendly RTOS environment using Espressif's MIT Licensed RTOS SDK
> release. To date these SDK releases from Espressif (RTOS 0.9.9 and
> earlier) are the only ones that incorporate an OSI-approved license,
> for the parts which are copyrighted by Espressif.

Well, as I mentioned, it's beyond irony to "build an open source
friendly RTOS environment" on an RTOS which has pretty cynical approach
towards open-source licensing and puts it upside down. Containing such
a component and then caring about "ones that incorporate an
OSI-approved license" for another component isn't too consistent
either. If FreeRTOS makes such twists in their interpretation of GPL,
then "the only ones that incorporate an OSI-approved license"-ness of
Espressif stuff doesn't cost much either (you may be told by Espressif
at any time).

> This means that reverse engineered copies of the binary libraries can
> immediately be BSD Licensed despite being derivative works. There's
> no need to prove clean room reverse engineering took place (which is
> very helpful, because proving this is very hard - doubly so in the
> context of community contributed code).

You're trying to build something logical on something with a glaring
contradiction, and that's known to be a logical error, producing
invalid results. As for reverse engineering, there're not worse
foundations for it, like fair use, interoperability, etc.

> As I mentioned on the github issue, the BSD licensed reverse
> engineered parts can be incorporated anywhere and put under any
> OSI-approved license. It would be fantastic if these libraries could
> be made RTOS-agnostic or ported to another OS. I was interested in
> Contiki back then, there are probably even more interesting options
> now.
>
> This is not yet possible without binary-level hacks, but we're an
> awful lot closer than we were in June 2015. To date the esp-open-rtos
> project contains the largest available quantity of usable open source
> licensed (OSI-approved) low-level system source code[*] for ESP8266
> and we should feel proud of this achievement.

That's definitely true, and from technical side, it's good that
esp-open-rtos exists (simply because different (better, all) direction
should be explored). My concern is with motivational matters (including
moral motivation thinking about wide Open Source community/movement).

However, if you want some technical/"reusability" feedback, I can
provide some anecdotal experience. esp-open-rtos is on top of my list
for open-source esp8266 code reuse, and on 2 occasions of
MicroPython/ESP8266 port I motivated 2 different people (not me!) to
reuse code from esp-open-rtos. In one case it was PWM support, in
another hardware SPI. It both cases they failed to make it work, and
had much easier time to reuse code from other sources. Again, anecdotal
experience, no implications. (Though I of course have to make
implications, as I essentially pushed 2 people twice to spend more
of their time than was needed, and an implication is "is esp-open-rtos
is really for code reuse, or a typical china-style hack-hack around
non-free RTOS?")

> In the future, if someone (maybe you) takes that code and ports the
> remaining binary library FreeRTOS dependencies to a new RTOS platform
> then I'll be delighted.
>
> Would it be possible to base an esp-open-rtos around an Espressif MIT
> Licensed SDK release? Of course, but if you want RTOS primitives then
> you still have all of the problems with reverse engineering binary
> libraries - either still with FreeRTOS or with an implementation
> where you don't have source code to read for the internals. If you
> succeed then at the end you're left with something which still isn't
> under an OSI-approved license and isn't legally any more open source
> than FreeRTOS is.

Of course it will be. Motivation for reverse engineering ESP8266 blobs
is fixing bugs and make it work in more environments, motivation for
FreeRTOS' pseudo-GPL is bordering on cynical abuse of Open Source for
marketing purpose. Technically, (preemptive) RTOS support consists of
non-RTOS primitive functions wrapped in threads, mutexes, and other
stuff.

> > So, for your kind information and as an input for making due
> > diligence checks and decisions in the future. You may also want to
> > check whether your Code of Conduct contains clauses along the lines
> > of: "We, the project maintainers, undertake to perform all the
> > decision, due diligence, and action process to uphold Open Source
> > nature of this project and wider Open Source community in general,
> > and to make all efforts to avoid deterioration of Open Source
> > community, principles, and values due to the work on this project,
> > or connected with how this project is being used."
>
> The purpose of the code of conduct is to ensure people feel welcome
> to suggest contributions and be involved in the project without fear
> of being harassed or abused, and to make it clear that harassing or
> abusive behaviour will not be tolerated.

That's why I'm not a fan of these code of conducts (for virtual projects
at least) - they state obvious things, and don't state many more, which
make them rather tube-vision.

>
>
> Angus
>
> [*] ESP8266 Arduino probably has the most open source driver-level
> and above source code written for ESP8266, which is also a very
> impressive achievement.

Good. As their code is LGPL, and I'm working on BSD/MIT projects, I'm
not looking deep in their code, so hope it's as good as you say.