Zephyr: Upstreamability of SiLabs RAIL support

[rettichschnidi]

Motivation

I am evaluating the SiLabs EFR32 Wireless Gecko SoCs for a new product. While the MCUs are already supported, I'd also need need Sub-GHz and/or Bluetooth support, which is not yet available in Zephyr. Having proper support in mainline Zephyr (willing to contribute it) is quite important because I do not want to maintain a private fork forever.

Problem

Unfortunately, it seems that upstreaming will be tricky because SiLabs does not document their radio hardware and to use the radio part of their SoCs, the usage of the RAIL library is needed. Which in turn causes some headache:

Legally

• The RAIL library is part of the Flex SDK, which is covered by the Silicon Labs Master Software License Agreement:

/***************************************************************************//**
 * @file                                                                        
 * @brief The main header file for the RAIL library. It describes the external  
 *   APIs available to a RAIL user                                              
 *******************************************************************************
 * # License                                                                    
 * <b>Copyright 2018 Silicon Laboratories Inc. www.silabs.com</b>               
 *******************************************************************************
 *                                                                              
 * The licensor of this software is Silicon Laboratories Inc. Your use of this  
 * software is governed by the terms of Silicon Labs Master Software License    
 * Agreement (MSLA) available at                                                
 * www.silabs.com/about-us/legal/master-software-license-agreement. This        
 * software is distributed to you in Source Code format and is governed by the  
 * sections of the MSLA applicable to Source Code.                              
 *                                                                              
 ******************************************************************************/

• Is there any other way than getting SiLabs to re-license their RAIL library in order to make upstream support possible from a legal standpoint?
  
  
  
  • (I do not think so, but Mbed OS is doing this. Do they have a special deal with SiLabs?)
  
  
• Would zlib licensed header (like their HAL sources) be acceptable despite them being depending on binary blobs?

Technically

The RAIL library supports GCC and IAR and consists of binary only blobs plus C headers.

• SiLabs recommends/supports just one exact compiler version - GCC 7.2.1 and IAR 8.30.1 as of 2019-06-23. Users of the SiLabs port of Zephyr therefore most likely want to use this version of GCC then. Is the Zephyr project willing to test (CI runs?) with a GCC version dictated by SiLabs? Or would I just have to rely on GCC being able to deal with .a files built with older versions of GCC?
• Using binary blobs will likely force Zephyr to (not) use a certain set of compiler flags in order to be compatible with the binaries. Is this feasible?

References

• This discussion has been briefly discussed on the mailing list in February 2018, but apparently did not yield any results
• TSC Meeting 2019-06-19
• PR [WIP] Silabs 802154 radio driver

[carlescufi]

Thank you for opening this issue @rettichschnidi.

We have discussed this particular issue in the last 2 TSC meetings. The resolution was that we would provide a proposal that then the TSC could vote on. I have updated the original issue I opened concerning binary blobs and non-standard licenses in #7516.

I would encourage you to join us on the next TSC call to discuss this from your perspective, as well as to help us decide what direction to move towards.

In #7516 I tried to summarize the different approaches we could take, always with the intention of this being a separate repository pulled in by west.

[carlescufi]

Is there any other way than getting SiLabs to re-license their RAIL library in order to make upstream support possible from a legal standpoint?

I believe the only way is to convince SiLabs to do so. I know that @kestewart wanted to talk to the company to see if they would be interested in relicensing them.

(I do not think so, but Mbed OS is doing this. Do they have a special deal with SiLabs?)

I don't think so, they included the license agreement in their tree, so they are just repackaging what SiLabs distributes.

Would zlib licensed header (like their HAL sources) be acceptable despite them being depending on binary blobs?

That depends on the resolution of #7516.
Another possibility, as I describe there, would be to include all the glue code in the zephyr main repo but require users to download headers and library separately.

[rettichschnidi]

I checked the Master Software License Agreement and it seems to me that the following section rules out all kind of possibility for Zephyr to ever host any SDK/Library with this license:

3.1. Object Code. With respect to Software (other than Micrium Software) that is delivered to Licensee by Silicon Labs in Object Code format, Licensee may:
3.1.1. (a) if the Software is an Embedded Stack, you may install one copy of the Software and its components all together on a single computer, and if the Software is copied onto another computer, the original copy must be deleted or otherwise made irreversibly inoperable; (b) if the Software is an SDK or a Development Tool, you may make multiple copies of the Software for your own internal use;

The whole point of upstreaming RAIL support is that one does not just want to use it internally. Therefore, limiting the distribution of object files to "own internal use" kills any upstreaming possibility.

3.2. Source Code. With respect to Software (other than Micrium Software) that is delivered to Licensee by Silicon Labs in Source Code format, Licensee may:
3.2.2. copy, prepare Derivative Works of, compile and modify Source Code of the Silicon Labs Software, solely to enable Licensee to design, develop, modify, test, support and/or debug Derivative Works and/or Licensed Programs that are intended to operate in Authorized Applications;

I think it will be impossible for Zephyr to ensure this.

1. License Restrictions.
   4.1. Without limiting the foregoing restriction, and except as authorized by this Agreement, Licensee shall not:
   4.1.1. assign, sublicense, or otherwise transfer the Licensed Materials to any third party;
   4.1.4. transmit Software over any network;
   4.1.6. distribute the Source Code form of Software to any third party, in whole or in part; or

:(

Section " 6. Open Source Software." has some nice provisions for open source software, but does state anything about pre-built, binary only blobs.

My conclusion: Without re-licensing RAIL, the Zepyhr project will not be able to meaningfully/easily integrate RAIL support.

[mnkp]

The version of RAIL shipped with Mbed OS comes with much less restrictive license. Though it also has a few points, e.g. export restrictions, that need to be verified from the legal standpoint.

[carlescufi]

@MaureenHelm @rettichschnidi @galak @nashif

I downloaded the SDK and browsed through it. The license for both the source code and object code can be found here:

https://www.silabs.com/about-us/legal/master-software-license-agreement

To me it's unclear whether this actually allows us to redistribute it. But one more thing to take into account is that when SiLabs themselves contributed RAIL to mbed, they actually did it under a different license: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_Silicon_Labs/TARGET_SL_RAIL/efr32-rf-driver/Silabs_License_Agreement.txt

That license is substantially less restrictive, so I wonder if we could just take the library from mbed under that license and use it?

EDIT: Sorry, I see that both @rettichschnidi and @mnkp had already pointed the above out. I had this pending and did not see the info, so there's a bit of repetition here.

[rettichschnidi]

@carlescufi What mbed has seems to be outdated. Also, the current RAIL versions have many more binaries.

Also, a short update after a discussion with my FAE contact: SiLabs is still evaluating. If and how they will support Zephyr will be decided in the coming weeks. Latest by the end of the month we will talk again.

[kestewart]

@rettichschnidi - just got off the phone with Silabs, and my contact working towards solving this as he's getting pressure from multiple FAEs for this to be fixed, so its up'd in priority. They're still assessing how much direct support for Zephyr, but fixing this licensing does seem to be a priority, independent of direct participation.

[rettichschnidi]

(Sorry for the late and small update)

End of July I had a call with our FAE. I got the same information as @kestewart: SiLabs seems motivated and moving forward, but they needs some more time. We will have another call latest by end of August.

[rettichschnidi]

Had another call: Still WIP, but still looking good.

[kestewart]

Just got off a call with SiLabs, and they plan on releasing it in their SDK update in December. I've asked if they can post the relevant files with the updated licensing before then, and they're looking into it.

[Oanerer]

As an FYI: the latest version of the SDK (2.7.0) now shows the RAIL library having the same Zlib license as the HAL:

/***************************************************************************//**
 * @file
 * @brief The main header file for the RAIL library. It describes the external
 *   APIs available to a RAIL user
 *******************************************************************************
 * # License
 * <b>Copyright 2018 Silicon Laboratories Inc. www.silabs.com</b>
 *******************************************************************************
 *
 * SPDX-License-Identifier: Zlib
 *
 * The licensor of this software is Silicon Laboratories Inc.
 *
 * This software is provided 'as-is', without any express or implied
 * warranty. In no event will the authors be held liable for any damages
 * arising from the use of this software.
 *
 * Permission is granted to anyone to use this software for any purpose,
 * including commercial applications, and to alter it and redistribute it
 * freely, subject to the following restrictions:
 *
 * 1. The origin of this software must not be misrepresented; you must not
 *    claim that you wrote the original software. If you use this software
 *    in a product, an acknowledgment in the product documentation would be
 *    appreciated but is not required.
 * 2. Altered source versions must be plainly marked as such, and must not be
 *    misrepresented as being the original software.
 * 3. This notice may not be removed or altered from any source distribution.
 *
 ******************************************************************************/

[rettichschnidi]

To be able to build against RAIL, more than just the headers are needed (i.e. the binary blobs). It seems however, that the Silicon Labs Master Software License Agreement is still in place, which specifically disallows redistribution.

Given this, would a Zephyr upstream port be feasible?

[conq]

I'm a Silicon Labs employee, and I initiated the license change in the past release.

Our intention for the license change is specifically to enable open source projects, such as Zephyr, to use RAIL and be able to redistribute it.

However, I'm only a well-intentioned engineer, and not a lawyer - so I'm poking our lawyers to see what we can do with the MLSA.

[conq]

Update:

I have now written a license.txt file that we'll distribute with our SDK in the future (hopefully the next patch release). Could someone from the Zephyr project tell me if this would be sufficient for your needs?

License.txt

[rettichschnidi]

Nice to see that SiLabs is reacting. Thanks!

Feedback (warning: I am not affiliated with Zephyr): I think that the direction is right, but that the zlib is not an appropriate license for the binary only parts.

[rettichschnidi]

@conq The topic is now on the agenda for the Technical Steering Committee (TSC) call on today. Maybe you can take part in it?

[carlescufi]

Update:

I have now written a license.txt file that we'll distribute with our SDK in the future (hopefully the next patch release). Could someone from the Zephyr project tell me if this would be sufficient for your needs?

License.txt

That is great, thank you. Would you consider also adding a LICENSE file in the platform/radio/rail_lib/autogen/librail_release folder that includes the zlib license text? That would help because then Zephyr could import that folder only and rely on the LICENSE file being there without any references to the SiLabs proprietary license. I don't think this is strictly required, but it would certainly help.

[carlescufi]

Nice to see that SiLabs is reacting. Thanks!

Feedback (warning: I am not affiliated with Zephyr): I think that the direction is right, but that the zlib is not an appropriate license for the binary only parts.

Talking about this, and perhaps something @conq might want to consider, is some of the licenses that are designed for binary-only code. There's a lot to pick and choose from here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/

[conq]

The rationale for going with Zlib for this is that it's a well-known license, and lawyers don't need to get involved to vet it. As far as I can tell (IANAL), it's fine - it's just weird, since #2 and #3 don't apply (since it's not a source distribution).

[chrta]

@stevew817 I did not find any license information in the current SDK for the files in platform/radio/rail_lib/autogen/librail_release Do you know when the license information will be available for these files, preferably by putting a LICENSE file in that folder.

[stevew817]

@chrta License.txt in the root of the SDK folder (v2.7) contains the following wording, which I think would suffice, but I'm not a lawyer.

Files under platform/radio/rail_lib/autogen/librail_release are distributed under the terms of the Zlib license

[chrta]

@stevew817 Thank you, i missed that. I just wanted to make sure that once we update the gecko sdk to the current version, we can also use the rails library files. I think we can do that now (but i am also not a lawyer...).

[markushx]

With the license change, would it be possible to include RAIL into https://github.com/zephyrproject-rtos/hal_silabs and re-open/update https://github.com/zephyrproject-rtos/zephyr/pull/11192?

[mnkp]

@markushx That's going to be a bit complicated. The RAIL library includes a binary blob and so far we don't have any in the main Zephyr tree or any of the modules. The Governing Board / TSC needs to approve it. I do hope this is going to happen. While no one likes it even Linux ships with 3rd party, closed source binary blobs.

I'm working on adding support for RAIL in Zephyr. I should send a PR in the next few days (preview is in my fork of hal_silabs and Zephyr). As I mentioned, the PR won't be merged unless approved by Governing Board / TSC.

[conq]

Also note that we cannot open-source this piece of code unfortunately. We enforce some FCC regulations in this blob.

[rettichschnidi]

@conq Which regulations exactly? Asking because a) FCC is not everywhere relevant and b) why can this responsibility not be put on the customer/users if they wanted it?

[rettichschnidi]

I realized that the master software License Agreement has been updated from 20190304 to 20200316. However, I could not spot any changes to the problematic sections identified earlier on in this issue. :(

[mnkp]

I realized that the master software License Agreement has been updated from 20190304 to 20200316. However, I could not spot any changes to the problematic sections identified earlier on in this issue. :(

The part that changed is in modules/hal/silabs/gecko/License.txt. It states

# Gecko SDK Licensing terms

Source code in this SDK is covered by one of several different licenses.
The default license is the Master Software License Agreement (MSLA) 
(https://www.silabs.com/about-us/legal/master-software-license-agreement),
which applies unless otherwise noted.

Some files use different licensing terms. If so, they will be clearly
marked in the beginning of the file.

Library files (either in archived or object form) are distributed under the
terms of the MSLA, with the following exceptions:

* Files under platform/radio/rail_lib/autogen/librail_release are distributed
  under the terms of the Zlib license.

[conq]

@rettichschnidi : I'm using FCC as shorthand here. Similar regulations exist in pretty much every jurisdiction. The problem is that we're selling ready-made modules. Part of the value for the customer is that they are pre-certified, meaning that if a customer uses a module in their design, they can skip large parts of the regulatory testing - which costs quite a bit of money. However, we only get that certification if we make sure that the module can't go out of spec (in particular with regards to transmission power). The exact wording varies from jurisdiction to jurisdiction, but that's the gist of it.

@mnkp : Yeah. Let me know if you need more code to be covered under zlib.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[rettichschnidi]

I am still interested and hoping that the board finds a good solution for this issue. Please remove the label.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[rettichschnidi]

Still interested. Please remove the label.