You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Justin Mclean <ju...@me.com> on 2016/02/05 03:50:53 UTC
Larva content review for license
Hi,
I just looked though all of the files in the larva repo to see how everything is licensed. I look at the other repos some time next week unless someone beats me to it.
If you’re not interested in licensing you can skip this as it’s long but there are a few minor issues that will need to be resolved at some point before graduation.
Summary:
- Most of what is bundled permissive BSD, MIT or public domain compatible with the Apache license. All good but makes for a long LICENSE file.
- Need to double check how mbed ARM files we use are licensed. Looks to be Apache.
- Probably remove this file .git/hooks/pre-rebase.sample (license in unknown)
- Remove or replace boot-stm32f3discovery.ld and stm32f3discovery.ld (license contains restrictions). Is this possible?
- Double check FatFS is permissive (It looks likely to me)
- Work how to deal with MCD-ST Liberty SW License
We could make a release without this issue being resolved if we bring attention to them and note so in the release note, so it doesn’t have to hold up the release plans.
The MCD-ST Liberty SW License is probably the biggest issue while it's BSD-like but includes this clause:
4. This software, including modifications and/or derivative works of this software, must execute solely and exclusively on microcontroller or microprocessor devices manufactured by or for STMicroelectronics.
We will probably have to raise a legal JIRA for this but lets discuss first. I assume the plan is for the code to run on there boards?
Also a minor thing should the NOTICE file mention Stack Inc, Runtime Inc or both?
In the repo is the following:
BSD licensed microjson
./libs/json/src/json_decode.c
Also BSD - Nordic Semiconductor
./hw/mcu/nordic/nrf5*
And BSD - The Regents of the University of California.
./libs/os/src/os_mbuf.c
./libs/os/include/os/queue.h
BSD - Kungliga Tekniska Högskolan
./libs/util/src/base64.c
BSD - KEIL (ARM Germany GmbH)
./libs/os/src/arch/cortex_m0/m0/HAL_CM0.s
./libs/os/src/arch/cortex_m0/m0/SVC_Table.s
./libs/os/src/arch/cortex_m4/m4/HAL_CM4.s
./libs/os/src/arch/cortex_m4/m4/SVC_Table.s
BSD-style (looks like Tcl/Tk license?)
CodeSourcery
./hw/bsp/nrf51dk/boot-nrf51dk.ld
./hw/bsp/nrf51dk/nrf51dk.ld
./hw/bsp/nrf51dk/nrf51dk_no_boot.ld
./hw/bsp/nrf52pdk/nrf52pdk.ld
Unknown from header but likely open source (see https://developer.mbed.org/blog/entry/mbed-SDK-is-now-Open-Source/)
mbed ARM:
./hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
./hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
./hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h
./hw/bsp/stm32f3discovery/include/bsp/cmsis_nvic.h
./libs/cmsis-core/src/cmsis_nvic.c
BSD ARM Limited
./hw/bsp/olimex_stm32-e407_devboard/src/arch/cortex_m4/startup_STM32F40x.s
BSD Georges Meni
./fs/nffs/src/crc16.c
./fs/nffs/src/crc16.h
Unknown but I assume can be removed?
# Copyright (c) 2006, 2008 Junio C Hamano
./.git/hooks/pre-rebase.sample
MIT Lua
./libs/elua/elua_base/src/lua.h
ISSUE! - Copyright Atollic AB
./hw/bsp/stm32f3discovery/boot-stm32f3discovery.ld
./hw/bsp/stm32f3discovery/stm32f3discovery.ld
As the header contains:
“This file may only be built (assembled or compiled and linked)
** using the Atollic TrueSTUDIO(R) product. The use of this file together
** with other tools than Atollic TrueSTUDIO(R) is not permitted.”
BSD cmsis core ARM LIMITED
./libs/cmsis-core/include/cmsis-core/*
BSD Baselibc Kustaa Nyholm / SpareTimeLabs
see ./libs/baselibc/LICENSE includes BSD licensed Tinyprintf and BSD files from Regents of The University of California, rest of the files are MIT
Dual licensed BSD / GPL Tinyprintf
./libs/baselibc/src/tinyprintf.c
MIT Lua
Also includes XMODEM (BSD), lpack (public domain), bit (MIT), integer only lua (PD), dlmalloc (PD), uIP (BSD), FatFs(?), Lua-RPC(?), linenoise (BSD)
I think the FatFS is permissive - see:
https://github.com/elua/elua/blob/master/LICENSE.fatfs (but this file is missing form the repo)
Lua RC is BSD but the file is missing from our repo.
https://github.com/elua/elua/blob/master/LICENSE.luarpc
Apache license - stack Inc
./hw/mcu/nordic/nrf51xxx/src/hal_cputime.c
./hw/mcu/nordic/nrf51xxx/src/hal_cputime.c
ISSUE! - Licensed under MCD-ST Liberty SW License Agreement V2
./hw/bsp/stm32f3discovery/src/arch/cortex_m4/startup_stm32f303xc.s
./hw/bsp/stm32f3discovery/src/system_stm32f30x.c
./hw/mcu/stm/stm32f3xx/include/mcu/*
./hw/mcu/stm/stm32f3xx/src/*
./hw/mcu/stm/stm32f4xx/include/mcu/system_stm32f4xx.h
+ a couple of other files
Thanks,
Justin
Re: Larva content review for license
Posted by marko kiiskila <ma...@runtime.io>.
> On Feb 5, 2016, at 9:02 AM, Sterling Hughes <st...@apache.org> wrote:
>
>
>>
>> However, the good thing is that the stm32f3xx driver library dependency
>> in actuality is pretty small. I can drop that altogether.
>>
>> Given that I brought it in, I can take it out.
>> —
>
> I also think it will be good to have one external dependency on GH. It adds a bit of visibility to start having a set of 3rd party packages :)
>
That sounds good, actually.
Re: Larva content review for license
Posted by Sterling Hughes <st...@apache.org>.
On 2/5/16 8:39 AM, marko kiiskila wrote:
> First of all; thanks for going through the licenses. This is good info.
>
>> On Feb 4, 2016, at 8:03 PM, Sterling Hughes <st...@apache.org> wrote:
>>
>>>
>>>> We can raise this with legal, alternatively we could move the MCU &
>>>> BSP definitions to github. People would need to config newt to point
>>>> at the github URL (newt add-clutch), but it would get around ASF
>>>> license issues.
>>>
>>> Only if it’s considered an optional dependancy, but I think that is the
>>> case. i.e. It not required for newt/larva to work. We had similar issue
>>> with Adobe licensed software and Apache Flex.
>>>
>>
>> It is an optional dependency. These files are board support headers and drivers for the STM32F3Discovery board. We'll have support for Nordic, Arduino, other STMicro boards in the default release - it would be just this board that was banished to Github. Plus, it will be fun to test out if our clutch system actually works :-)
>
> Ah, well that finding is inconvenient.
>
> However, the good thing is that the stm32f3xx driver library dependency
> in actuality is pretty small. I can drop that altogether.
>
> Given that I brought it in, I can take it out.
> —
I also think it will be good to have one external dependency on GH. It
adds a bit of visibility to start having a set of 3rd party packages :)
Sterling
Re: Larva content review for license
Posted by marko kiiskila <ma...@runtime.io>.
First of all; thanks for going through the licenses. This is good info.
> On Feb 4, 2016, at 8:03 PM, Sterling Hughes <st...@apache.org> wrote:
>
>>
>>> We can raise this with legal, alternatively we could move the MCU &
>>> BSP definitions to github. People would need to config newt to point
>>> at the github URL (newt add-clutch), but it would get around ASF
>>> license issues.
>>
>> Only if it’s considered an optional dependancy, but I think that is the
>> case. i.e. It not required for newt/larva to work. We had similar issue
>> with Adobe licensed software and Apache Flex.
>>
>
> It is an optional dependency. These files are board support headers and drivers for the STM32F3Discovery board. We'll have support for Nordic, Arduino, other STMicro boards in the default release - it would be just this board that was banished to Github. Plus, it will be fun to test out if our clutch system actually works :-)
Ah, well that finding is inconvenient.
However, the good thing is that the stm32f3xx driver library dependency
in actuality is pretty small. I can drop that altogether.
Given that I brought it in, I can take it out.
—
M
Re: Larva content review for license
Posted by Sterling Hughes <st...@apache.org>.
>> rel_v0_0_8-b1 for example.
>>
>> - newt's built in package manager knows to fetch packages from that
>> git branch (we make the changes to newt once we branch.)
>
> May be an issue with this (I think not 100% sure), does that imply that
> a release can basically change over time? Or that it would be
> downloading un-released software?
>
I misspoke, it's probably a tag not a branch. I guess somebody could
always move a tag, but somebody can always replace a tarball too.
I'm pretty flexible about how we push this out -- feedback and thoughts
are really welcome. Let me give some quick technical background for the
uninitiated.
<way too long explanation>
newt is the build and package management tool that pulls the various
components of our OS together and generates builds. A collection of
eggs (packages), forms a nest. And newt knows how to build all the eggs
in a nest. "Larva" is our default nest, with a collection of eggs.
In newt, you can generate what is called a clutch. A clutch is a
snapshot of the eggs in a given nest at a given point in time. As an
example, here is the start of a clutch file generated on git master larva:
$ newt nest generate-clutch larva http://mynewt.apache.org
name: larva
url: http://mynewt.apache.org
eggs:
project/test:
vers: 0.1.0
hash: 8de883b9aa460677bb79da3c495fc654186b017e
deps:
- fs/nffs@none#stable
- libs/testutil@none#stable
- libs/os@none#stable
- libs/bootutil@none#stable
- libs/testreport@none#stable
hw/bsp/stm32f3discovery:
vers: 0.0.0
hash: 73f2aa944dec135e07891f4f0a1e154858b99024
deps:
- hw/mcu/stm/stm32f3xx@none#stable
project/blinky:
<snip>
A user can configure newt to look at remote clutch files (HTTP or GIT),
and newt will go read those files and install them in the user's local
nest (along with resolving any dependencies.)
The idea is that the core of Mynewt will mature in the ASF, and people
will get the default set of packages from there, and those packages will
track along with overall project maturity (e.g. they'll be stable
someday :-)
However, around this core, hopefully people will be adding all sorts of
cool things around Mynewt. These could be either Apache sub-projects
(ala Hadoop ecosystem), corporations who share code across projects or
just some guy who happened to put a cool library on Github. Each of
these would generate and distribute their own clutch-file, which the
newt tool can be pointed at.
</way too long explanation>
> For something to be a release it must be voted on and while in
> incubation also voted on by the incubator PMC. So as long at that git
> branch only contained approved software that would be fine.
Agree.
>
>> - We build newt for all supported platforms (Linux, Mac OS X, Windows)
>> -- and we distribute that, along with necessary LICENSE files on our
>> website.
>
> Best to distribute via the apache mirrors, there a cgi script you can
> use to grab the artefacts from the nearest mirror. Not there must needs
> to be a source only release and an optional binary convenience release.
>
Agree. We'll need some help with this once we've got the tarballs.
>> - Those eggs then come with individual LICENSE files, which have their
>> license info.
>
> Yep the LICENSE (and NOTICE) files need to reflect only what is bundled
> in the artefact downloaded.
>
>> They are Apache -- can you point me to the specific files you're
>> referencing so I can double check?
> ./hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
> ./hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
> ./hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h
> ./hw/bsp/stm32f3discovery/include/bsp/cmsis_nvic.h
> ./libs/cmsis-core/src/cmsis_nvic.c
>
Thanks I'll dig into these & report back.
>> Anyhow, here is the FatFs license, it is liberal
>
> Yep no issue there.
>
>> We can raise this with legal, alternatively we could move the MCU &
>> BSP definitions to github. People would need to config newt to point
>> at the github URL (newt add-clutch), but it would get around ASF
>> license issues.
>
> Only if it’s considered an optional dependancy, but I think that is the
> case. i.e. It not required for newt/larva to work. We had similar issue
> with Adobe licensed software and Apache Flex.
>
It is an optional dependency. These files are board support headers and
drivers for the STM32F3Discovery board. We'll have support for Nordic,
Arduino, other STMicro boards in the default release - it would be just
this board that was banished to Github. Plus, it will be fun to test
out if our clutch system actually works :-)
Sterling
Re: Larva content review for license
Posted by Justin Mclean <ju...@me.com>.
Hi,
> Replies are inline. One general comment: I think we should have MAINTAINERS and a MAINTAINER file.
It’s not encouraged, people can come and go on a project and it could encourage off list traffic. If you really want to know who’s working on something you can check out version control history.
> That way if people have a problem, they know who to contact with questions. Thoughts?
It better that questions are sent to the dev list, where anyone can help, not to individuals.
> When we do release packaging, the way I was thinking about it (and apologies, I was going to send a longer mail but you beat me to it) was:
>
> - we branch the git repo at a specific version (larva & newt) -- rel_v0_0_8-b1 for example.
>
> - newt's built in package manager knows to fetch packages from that git branch (we make the changes to newt once we branch.)
May be an issue with this (I think not 100% sure), does that imply that a release can basically change over time? Or that it would be downloading un-released software?
For something to be a release it must be voted on and while in incubation also voted on by the incubator PMC. So as long at that git branch only contained approved software that would be fine.
> - We build newt for all supported platforms (Linux, Mac OS X, Windows) -- and we distribute that, along with necessary LICENSE files on our website.
Best to distribute via the apache mirrors, there a cgi script you can use to grab the artefacts from the nearest mirror. Not there must needs to be a source only release and an optional binary convenience release.
> - Those eggs then come with individual LICENSE files, which have their license info.
Yep the LICENSE (and NOTICE) files need to reflect only what is bundled in the artefact downloaded.
> They are Apache -- can you point me to the specific files you're referencing so I can double check?
./hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
./hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
./hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h
./hw/bsp/stm32f3discovery/include/bsp/cmsis_nvic.h
./libs/cmsis-core/src/cmsis_nvic.c
> Anyhow, here is the FatFs license, it is liberal
Yep no issue there.
> We can raise this with legal, alternatively we could move the MCU & BSP definitions to github. People would need to config newt to point at the github URL (newt add-clutch), but it would get around ASF license issues.
Only if it’s considered an optional dependancy, but I think that is the case. i.e. It not required for newt/larva to work. We had similar issue with Adobe licensed software and Apache Flex.
Thanks,
Justin
Re: Larva content review for license
Posted by Sterling Hughes <st...@apache.org>.
On 2/4/16 7:55 PM, Justin Mclean wrote:
> Hi,
>
>> If you'd like to create an overall shout-out, then go for it. The
>> Subversion project does this, and uses the same file to track partial
>> commit (as Mynewt has adopted). See:
>> http://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS
>
> Apache Flex does this a little differently and names people by release:
> https://github.com/apache/flex-sdk/blob/develop/CONTRIBUTORS
>
> (Note this includes people who are not committers, the idea behind it was to encourage them to become so.)
>
> But it not a requirement and each PMC can decide on how to or not do it.
>
This seems good to me.
At some point it seems like we'll want MAINTAINERS, as there is a fair
amount of specialization (an OS is technically very broad.) But I guess
we can start breaking things into sub-projects when we hit that problem.
(*)
Sterling
(*) As an example, net/nimble is the _first_ open-source Bluetooth stack
(both Host & Controller) for MCUs. Given contributor bandwidth, IMO it
makes sense to bundle governance in with Mynewt, but over time I could
imagine this being MCU agnostic and being its own Apache project in the
Mynewt ecosystem.
Re: Larva content review for license
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> If you'd like to create an overall shout-out, then go for it. The
> Subversion project does this, and uses the same file to track partial
> commit (as Mynewt has adopted). See:
> http://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS
Apache Flex does this a little differently and names people by release:
https://github.com/apache/flex-sdk/blob/develop/CONTRIBUTORS
(Note this includes people who are not committers, the idea behind it was to encourage them to become so.)
But it not a requirement and each PMC can decide on how to or not do it.
Thanks,
Justin
Re: Larva content review for license
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> it is really silly that they have that proviso in there, because they are unusable on any other platform except their own.
My guess is that want to have a legal leg to stand on if people making clones of their boards?
Justin
Re: Larva content review for license
Posted by Sterling Hughes <st...@apache.org>.
>
> ISSUE! - Licensed under MCD-ST Liberty SW License Agreement V2
>
> ./hw/bsp/stm32f3discovery/src/arch/cortex_m4/startup_stm32f303xc.s
> ./hw/bsp/stm32f3discovery/src/system_stm32f30x.c
> ./hw/mcu/stm/stm32f3xx/include/mcu/*
> ./hw/mcu/stm/stm32f3xx/src/*
> ./hw/mcu/stm/stm32f4xx/include/mcu/system_stm32f4xx.h
> + a couple of other files
>
>
> We can raise this with legal, alternatively we could move the MCU &
> BSP definitions to github. People would need to config newt to
> point at the github URL (newt add-clutch), but it would get around
> ASF license issues.
>
> Personally, I'm leaning heavily towards this option: I think code
> from the default ASF repository should be pure, as otherwise people
> will adopt packages thinking they are Apache licensed and find out
> later they are not.
>
>
> It is not allowed to release a package with such a "gotcha" :-) ... so
> yes, a solution where an *optional* feature can be selected by the user,
> understanding they are then restricted by the licensing of that optional
> feature. ... will Mynewt be useful for other platforms besides STM (eg.
> ARM) without that optional github-based feature?
>
Yup-- and at least for one of the files, they have an alternative file
that doesn't have this license. So we'll likely be able to use our OS
on another processor in the same exact family. These are header files
and startup files that are specifically targeted to the STMicro
processors: it is really silly that they have that proviso in there,
because they are unusable on any other platform except their own.
Sterling
Re: Larva content review for license
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Feb 4, 2016 at 9:10 PM, Sterling Hughes <st...@apache.org> wrote:
> First off Justin, thank you! This is very much appreciated.
>
> Replies are inline. One general comment: I think we should have
> MAINTAINERS and a MAINTAINER file. MAINTAINERS should be in larva/ and
> MAINTAINER should be in each individual egg. That way if people have a
> problem, they know who to contact with questions. Thoughts?
I'd say "no". Please do not associate any file or group of files with
specific people. Mynewt is owned, managed, developed, and maintained by the
*community*. All problems, questions, patches, etc should come to the
community. Not a person.
If you'd like to create an overall shout-out, then go for it. The
Subversion project does this, and uses the same file to track partial
commit (as Mynewt has adopted). See:
http://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS
>...
> ISSUE! - Licensed under MCD-ST Liberty SW License Agreement V2
>>
> ./hw/bsp/stm32f3discovery/src/arch/cortex_m4/startup_stm32f303xc.s
>> ./hw/bsp/stm32f3discovery/src/system_stm32f30x.c
>> ./hw/mcu/stm/stm32f3xx/include/mcu/*
>> ./hw/mcu/stm/stm32f3xx/src/*
>> ./hw/mcu/stm/stm32f4xx/include/mcu/system_stm32f4xx.h
>> + a couple of other files
>>
>>
> We can raise this with legal, alternatively we could move the MCU & BSP
> definitions to github. People would need to config newt to point at the
> github URL (newt add-clutch), but it would get around ASF license issues.
>
> Personally, I'm leaning heavily towards this option: I think code from the
> default ASF repository should be pure, as otherwise people will adopt
> packages thinking they are Apache licensed and find out later they are not.
It is not allowed to release a package with such a "gotcha" :-) ... so yes,
a solution where an *optional* feature can be selected by the user,
understanding they are then restricted by the licensing of that optional
feature. ... will Mynewt be useful for other platforms besides STM (eg.
ARM) without that optional github-based feature?
Cheers,
-g
Re: Larva content review for license
Posted by Sterling Hughes <st...@apache.org>.
First off Justin, thank you! This is very much appreciated.
Replies are inline. One general comment: I think we should have
MAINTAINERS and a MAINTAINER file. MAINTAINERS should be in larva/ and
MAINTAINER should be in each individual egg. That way if people have a
problem, they know who to contact with questions. Thoughts?
On 2/4/16 6:50 PM, Justin Mclean wrote:
> Hi,
>
> I just looked though all of the files in the larva repo to see how everything is licensed. I look at the other repos some time next week unless someone beats me to it.
>
> If you’re not interested in licensing you can skip this as it’s long but there are a few minor issues that will need to be resolved at some point before graduation.
>
> Summary:
> - Most of what is bundled permissive BSD, MIT or public domain compatible with the Apache license. All good but makes for a long LICENSE file.
When we do release packaging, the way I was thinking about it (and
apologies, I was going to send a longer mail but you beat me to it) was:
- we branch the git repo at a specific version (larva & newt) --
rel_v0_0_8-b1 for example.
- newt's built in package manager knows to fetch packages from that git
branch (we make the changes to newt once we branch.)
- We build newt for all supported platforms (Linux, Mac OS X, Windows)
-- and we distribute that, along with necessary LICENSE files on our
website.
- Newt can create nests (the default nest is the contents of tadpole,
which is autogenerated from larva.)
- Newt can download eggs into that nest (newt egg install net/nimble, to
install the BLE stack, for example.)
- Those eggs then come with individual LICENSE files, which have their
license info.
Does this sound good?
> - Need to double check how mbed ARM files we use are licensed. Looks to be Apache.
They are Apache -- can you point me to the specific files you're
referencing so I can double check?
> - Probably remove this file .git/hooks/pre-rebase.sample (license in unknown)
K
> - Remove or replace boot-stm32f3discovery.ld and stm32f3discovery.ld (license contains restrictions). Is this possible?
Yes
> - Double check FatFS is permissive (It looks likely to me)
We haven't bundled this, this is just in elua's license file. Anyhow,
here is the FatFs license, it is liberal:
------------------------------/
/ FatFs - FAT file system module R0.11a (C)ChaN, 2015
/
/-----------------------------------------------------------------------------/
/ FatFs module is a free software that opened under license policy of
/ following conditions.
/
/ Copyright (C) 2015, ChaN, all right reserved.
/
/ 1. Redistributions of source code must retain the above copyright notice,
/ this condition and the following disclaimer.
/
/ This software is provided by the copyright holder and contributors "AS IS"
/ and any warranties related to this software are DISCLAIMED.
/ The copyright owner or contributors be NOT LIABLE for any damages caused
/ by use of this software.
/----------------------------------------------------------------------------*/
> - Work how to deal with MCD-ST Liberty SW License
>
> We could make a release without this issue being resolved if we bring attention to them and note so in the release note, so it doesn’t have to hold up the release plans.
>
> The MCD-ST Liberty SW License is probably the biggest issue while it's BSD-like but includes this clause:
> 4. This software, including modifications and/or derivative works of this software, must execute solely and exclusively on microcontroller or microprocessor devices manufactured by or for STMicroelectronics.
>
> We will probably have to raise a legal JIRA for this but lets discuss first. I assume the plan is for the code to run on there boards?
>
See below.
> Also a minor thing should the NOTICE file mention Stack Inc, Runtime Inc or both?
Runtime Inc.
>
> In the repo is the following:
>
> BSD licensed microjson
> ./libs/json/src/json_decode.c
>
> Also BSD - Nordic Semiconductor
> ./hw/mcu/nordic/nrf5*
>
> And BSD - The Regents of the University of California.
> ./libs/os/src/os_mbuf.c
> ./libs/os/include/os/queue.h
>
> BSD - Kungliga Tekniska Högskolan
> ./libs/util/src/base64.c
>
> BSD - KEIL (ARM Germany GmbH)
> ./libs/os/src/arch/cortex_m0/m0/HAL_CM0.s
> ./libs/os/src/arch/cortex_m0/m0/SVC_Table.s
> ./libs/os/src/arch/cortex_m4/m4/HAL_CM4.s
> ./libs/os/src/arch/cortex_m4/m4/SVC_Table.s
>
> BSD-style (looks like Tcl/Tk license?)
> CodeSourcery
> ./hw/bsp/nrf51dk/boot-nrf51dk.ld
> ./hw/bsp/nrf51dk/nrf51dk.ld
> ./hw/bsp/nrf51dk/nrf51dk_no_boot.ld
> ./hw/bsp/nrf52pdk/nrf52pdk.ld
>
> Unknown from header but likely open source (see https://developer.mbed.org/blog/entry/mbed-SDK-is-now-Open-Source/)
> mbed ARM:
> ./hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
> ./hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
> ./hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h
> ./hw/bsp/stm32f3discovery/include/bsp/cmsis_nvic.h
> ./libs/cmsis-core/src/cmsis_nvic.c
>
> BSD ARM Limited
> ./hw/bsp/olimex_stm32-e407_devboard/src/arch/cortex_m4/startup_STM32F40x.s
>
> BSD Georges Meni
> ./fs/nffs/src/crc16.c
> ./fs/nffs/src/crc16.h
>
> Unknown but I assume can be removed?
> # Copyright (c) 2006, 2008 Junio C Hamano
> ./.git/hooks/pre-rebase.sample
Yes
>
> MIT Lua
> ./libs/elua/elua_base/src/lua.h
>
> ISSUE! - Copyright Atollic AB
> ./hw/bsp/stm32f3discovery/boot-stm32f3discovery.ld
> ./hw/bsp/stm32f3discovery/stm32f3discovery.ld
>
> As the header contains:
> “This file may only be built (assembled or compiled and linked)
> ** using the Atollic TrueSTUDIO(R) product. The use of this file together
> ** with other tools than Atollic TrueSTUDIO(R) is not permitted.”
>
These need to go. We'll replace them.
> BSD cmsis core ARM LIMITED
> ./libs/cmsis-core/include/cmsis-core/*
>
> BSD Baselibc Kustaa Nyholm / SpareTimeLabs
> see ./libs/baselibc/LICENSE includes BSD licensed Tinyprintf and BSD files from Regents of The University of California, rest of the files are MIT
>
> Dual licensed BSD / GPL Tinyprintf
> ./libs/baselibc/src/tinyprintf.c
>
> MIT Lua
> Also includes XMODEM (BSD), lpack (public domain), bit (MIT), integer only lua (PD), dlmalloc (PD), uIP (BSD), FatFs(?), Lua-RPC(?), linenoise (BSD)
>
> I think the FatFS is permissive - see:
> https://github.com/elua/elua/blob/master/LICENSE.fatfs (but this file is missing form the repo)
>
> Lua RC is BSD but the file is missing from our repo.
> https://github.com/elua/elua/blob/master/LICENSE.luarpc
>
We need to add this. Marko, you are maintaining elua, can you add?
> Apache license - stack Inc
> ./hw/mcu/nordic/nrf51xxx/src/hal_cputime.c
> ./hw/mcu/nordic/nrf51xxx/src/hal_cputime.c
This should be runtime.
>
> ISSUE! - Licensed under MCD-ST Liberty SW License Agreement V2
> ./hw/bsp/stm32f3discovery/src/arch/cortex_m4/startup_stm32f303xc.s
> ./hw/bsp/stm32f3discovery/src/system_stm32f30x.c
> ./hw/mcu/stm/stm32f3xx/include/mcu/*
> ./hw/mcu/stm/stm32f3xx/src/*
> ./hw/mcu/stm/stm32f4xx/include/mcu/system_stm32f4xx.h
> + a couple of other files
>
We can raise this with legal, alternatively we could move the MCU & BSP
definitions to github. People would need to config newt to point at the
github URL (newt add-clutch), but it would get around ASF license issues.
Personally, I'm leaning heavily towards this option: I think code from
the default ASF repository should be pure, as otherwise people will
adopt packages thinking they are Apache licensed and find out later they
are not.
Sterling
Re: Larva content review for license
Posted by Justin Mclean <ju...@me.com>.
Hi,
Forgot to include the link to the troublsome license:
http://www.st.com/web/en/resource/legal/legal_agreement/license_agreement/ultimate-liberty-v2.txt?sc=software_license_agreement_liberty_v2
Thanks,
Justin