Hi,
I currently detect that openthread will be use internally some mbedtls as some library for crypto stuff. This license is apache [0].
Will this not clash with RIOT's LGPL? Or does there exists some replacement for such functionality under another license?
- Alex
[0] https://github.com/openthread/openthread/blob/master/third_party/mbedtls/repo/LICENSE
Hi Alex, we include openthread’s source code as a package so as far as we are concerned (but we are not lawyers) there is no licensing issue. If you know anything different, please let us know!
Cheers, Martine
Hi,
Hi Alex, we include openthread's source code as a package so as far as we are concerned (but we are not lawyers) there is no licensing issue. If you know anything different, please let us know!
I am also not a lawyer. I think I got confused because
"WHICH LICENSES MAY NOT BE INCLUDED WITHIN APACHE PRODUCTS?"
from [0]. But RIOT is not an "APACHE PRODUCT"... , 
but then I still don't get something - there was a discussion about jerryscript in RIOT at riot-summit. Jerryscript is also apache license and the discussion was about license issues between jerryscript and RIOT.
I don't see a difference here now. Maybe somebody knows more? :-/
- Alex
Hi all, I have the same problem (I’m preparing the IoTivity Pkg) and I asked to Emmanuel how can I solve it. He answered:
The OpenThread RIOT Pkg is composed by Makefiles and some code released under LGPLv2.1 license. The OT code is downloaded during the compilation phase. I guess there is not any license issue because the PRed code is compliant with the RIOT license.
Have a nice day,
Mattia
Hi Alex,
Hi,
"WHICH LICENSES MAY NOT BE INCLUDED WITHIN APACHE PRODUCTS?"
from [0]. But RIOT is not an "APACHE PRODUCT"... ,
Well we do it the other way around, we include (in this instant I mean linking) a non-LGPL product within a LGPL product. The code itself isn't even included, but downloaded from source. AFAIK this is fine*.
I think what Alexander wants to point out is that above statement can be misread as "Apache 2.0 and LGPLv2.1 are incompatible from Apache's perspective.
Here [1] is an interesting thread which should clarify the issue. In essence, the Apache foundation has a *policy* that *Apache foundation projects* may not use mandatory LGPL'ed components, in order for downstream users to not have to deal with LGPL's requirements.
That does not mean that the Apache License 2.0 ("AL 2.0") is incompatible with LGPLv2.1.
I've contacted the FSF (again) to clarify our specific "AL 2.0 package" problem, and I'm waiting for them to answer. But currently I read the licenses as follows:
1. LGPLv2.1 does not consider a released binary as derivative work if the LGPL'ed code is only linked to non-LGPL'ed code, and the distributor of that combined work distributes the means necessary to replace and/or debug the LGPL'ed part. As packages are available as source, this constraint is satisfied, thus from the LGPLv2.1 perspective using AL 2.0 packages is fine.
2. AL 2.0 has a linking exception: "For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof." Thus using an AL 2.0 as package is fine.
Kaspar
Hi All,
Any news on this topic?
Cheers,
Mattia
Hey,
Any news on this topic?
Yes, FSF answered:
"
Specifically, can we use Apache 2.0 licensed "packages" this way?
When someone who isn't the copyright holder of RIOT OS wants to further distribute your work, they can only do so under the terms you have specified. In this case the terms of LGPLv2.1.
If a third party wants to distribute a work which used your build system (or any other system for that matter) to create a statically linked work which includes RIOT OS and software licensed under the terms of the the Apache 2.0 license, the terms of LGPLv2.1 (section 6.a) require that third party to also provide the Apache 2.0 licensed work in an object (not necessarily source) format which would allow the recipients to relink against a modified version of RIOT OS.
Also see: Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation "
I tried to clarify whether source is sufficient:
"
"not necessarily source" means that if source is available (as would be the case for AL2.0 code), that is sufficient, correct?
Section 6.a of LGPLv2.1 requires that if someone distributes an executable linked with the library, that they actually accompany that executable with the object or source code which would enable re-linking:
"""... Accompany the work with the complete corresponding machine-readable source code for the Library... and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code ...""" "
Cheers, Kaspar
Hi Kaspar,