You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Christopher Collins <cc...@apache.org> on 2016/11/09 20:46:00 UTC
Nordic SDK license not Apache-compatible?
Hello all,
I was checking some of the licenses in Mynewt, and I came across a
potential licensing issue. The Nordic SDK v11 appears to use a license
that is too restrictive for an Apache project:
http://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v11.x.x/doc/11.0.0/license.txt
The first clause, Grant of License, seems to be problematic:
1. Grant of License
Subject to the terms in this Agreement Nordic grants Licensee a
limited, non-exclusive, non-transferable, non-sub licensable,
revocable license ("License"): (a) to use the SDK as a development
platform solely in connection with a Nordic Integrated Circuit ("nRF
IC"), (b) to modify any source code contained in the SDK solely as
necessary to implement products developed by Licensee that
incorporate an nRF IC ("Licensee Product"), and (c) to distribute
the SDK solely as implemented in Licensee Product. Licensee shall
not use the SDK for any purpose other than specifically authorized
herein.
I see that ARM got permission to replace this license with a BSD license
in some of the SDK files
(https://github.com/ARMmbed/ble-nrf51822/issues/1). Unfortunately, they
don't use all the files we need, so we can't just replace our version
with the one from the mbed repo.
Does anyone happen to have any magic solution to this problem? Maybe
Nordic has indicated somewhere that these files are meant to be
BSD-licensed?
Thanks,
Chris
Re: Nordic SDK license not Apache-compatible?
Posted by Christopher Collins <cc...@apache.org>.
Hello all,
I wanted to provide a quick update on the Nordic SDK licensing issue.
This issue has been resolved as follows:
* Some of the SDK functionality has been separately implemented with
an Apache license. This code remains in the apache-mynewt-core
repository.
* A new github repository was created. The new repository contains
the incompatible parts of the Nordic SDK, as well as the Mynewt
drivers which depend on those parts. This is similar to what was
done with the mynewt_arduino_zero repo.
I believe most projects won't be affected by this change. However, if
you are using the Nordic ADC driver, or if you are using the Nordic SDK
directly, then your app will need to depend on a package in the new
repo. This is done as follows:
1. Add the following repo dependency to your project.yml file:
repository.mynewt_nordic:
type: github
vers: 0-latest
user: runtimeinc
repo: mynewt_nordic
2. Add the following package dependency to your app's pkg.yml file.
@mynewt_nordic/hw/mcu/nordic_sdk
This change has only been pushed to the 1_0_0_b1_dev branch, but it will
get merged to develop and master soon.
Thanks,
Chris
On Thu, Nov 10, 2016 at 01:48:49PM +0100, Sterling Hughes wrote:
> I\u2019ve contacted Nordic. This seems like a concern shared by us, mbed
> and zephyr.
>
> Question for Justin (and others too) re exceptions during beta releases.
> Assuming Nordic is not going to relicense this in time for our beta
> release, I think we have 2 options in front of us:
>
> 1- Remove Nordic drivers from our source code, and distribute Nordic
> separately as Runtime. We do this today, with the Arduino Zero, because
> of the Atmel licensed header files.
>
> It is really _not_ ideal to do this for a few reasons:
>
> a- As a project, in order to run on our major platforms, the ASF is
> relying on code that is maintained and managed by Runtime. Speaking for
> runtime, we\u2019re happy to do this and be good citizens, but long term
> we\u2019d really like this to be owned by the Mynewt project.
>
> b- Another option here would be to contact Nordic and ask them to
> maintain the port to Mynewt. Which would be a better option for
> Runtime, but still as a project, probably not ideal. :-)
>
> 2- Atmel has confirmed that Runtime and/or the Mynewt project is not
> violating their license in the way which we redistribute these header
> files. My guess is we can get a similar statement from Nordic, along
> with a statement that they are working on re-licensing these header
> files. We can decide to redistribute these files with our core release,
> which would be ideal, and add them to an exception file, which clearly
> spells out that these files are _not_ an approved Apache license.
>
> I think this would be the ideal scenario, as we work to address license
> issues with the various MCU vendors. These license clauses are not
> overly restrictive (*), but more of a nuisance. I think if we all took
> the perspective of a user, this would be the preferable approach,
> instead of making them install these header files elsewhere.
>
> _Especially_ in the context of a beta release: we can make a different
> decision prior to 1.0, if we can\u2019t address the license issue
> sufficiently/get Nordic to relicense these header files in time.
>
> Sterling
>
> (*) The header file licenses, in the case of both Atmel and Nordic,
> simply state that this source code can only be used in conjunction with
> a product that runs on their hardware platform. It is otherwise a
> 3-clause BSD license. The source code in question, is driver and header
> files for their platform: so, it wouldn\u2019t make sense to use it any
> other way.
>
> I\u2019m not advocating these clauses, but I think from a user perspective,
> its not exactly going to restrict use / open them up to risk. As they
> will only be using this source on a nordic platform.
>
>
> On 10 Nov 2016, at 2:18, Kevin Townsend wrote:
>
> > We have a similar problem with Nordic code where due to older
> > restrictive license terms we can't release the source for some
> > projects. The terms have gotten friendlier with time, but the earliest
> > stuff was quite restrictive.
> >
> > I'd suggest getting in touch with Nordic, though. They're probably
> > open to making some changes in certain situations. If you need a
> > contact there, just send me a private email but I know Sterling
> > already knows a mutual contact that would be a good person to explain
> > the issue to and hopefully get the ball rolling on what will ideally
> > lead to compatible license terms(???). It seems like it would be in
> > their interest and most of this code isn't useful on anything other
> > than their own silicon anyway.
> >
> > On 10/11/16 02:12, Christopher Collins wrote:
> >> Hi Justin,
> >>
> >> On Thu, Nov 10, 2016 at 08:33:54AM +1100, Justin Mclean wrote:
> >>> Hi,
> >>>
> >>>> The first clause, Grant of License, seems to be problematic:
> >>> Look like it "non-sub licensable\u201d may be an issue? And "solely in
> >>> connection with a Nordic Integrated Circuit\u201d reads like a field of
> >>> use
> >>> restriction to me [1]
> >>>
> >>> Section 4 of the license re distribution may also be a concern.
> >> That was indeed my fear. Thanks for calling attention to section 4
> >> as
> >> well.
> >>
> >>> Their modified BSD license also may be an issue as it also looks to
> >>> includes a field of use restriction.
> >> You are right - I hadn't noticed that. However, the fourth clause
> >> is missing in the actual commits that were made to address this
> >> ticket
> >> (https://github.com/ARMmbed/ble-nrf51822/commit/6d1bf116e156b870099694f0ce27076c236c4f44).
> >> Maybe there was some additional communication between the mbed team
> >> and Nordic that let to the actual changes.
> >>
> >>> I assume this is optional in that not everyone would need to use it?
> >> Yes, these files are optional in the sense that Mynewt can still be
> >> used without them. However, someone wishing to use Mynewt with a
> >> Nordic
> >> MCU will probably won't get very far without them.
> >>
> >>> 1. https://www.apache.org/legal/resolved#category-x
> >> Thanks, Chris
> >
Re: Nordic SDK license not Apache-compatible?
Posted by Sterling Hughes <st...@apache.org>.
I’ve contacted Nordic. This seems like a concern shared by us, mbed
and zephyr.
Question for Justin (and others too) re exceptions during beta releases.
Assuming Nordic is not going to relicense this in time for our beta
release, I think we have 2 options in front of us:
1- Remove Nordic drivers from our source code, and distribute Nordic
separately as Runtime. We do this today, with the Arduino Zero, because
of the Atmel licensed header files.
It is really _not_ ideal to do this for a few reasons:
a- As a project, in order to run on our major platforms, the ASF is
relying on code that is maintained and managed by Runtime. Speaking for
runtime, we’re happy to do this and be good citizens, but long term
we’d really like this to be owned by the Mynewt project.
b- Another option here would be to contact Nordic and ask them to
maintain the port to Mynewt. Which would be a better option for
Runtime, but still as a project, probably not ideal. :-)
2- Atmel has confirmed that Runtime and/or the Mynewt project is not
violating their license in the way which we redistribute these header
files. My guess is we can get a similar statement from Nordic, along
with a statement that they are working on re-licensing these header
files. We can decide to redistribute these files with our core release,
which would be ideal, and add them to an exception file, which clearly
spells out that these files are _not_ an approved Apache license.
I think this would be the ideal scenario, as we work to address license
issues with the various MCU vendors. These license clauses are not
overly restrictive (*), but more of a nuisance. I think if we all took
the perspective of a user, this would be the preferable approach,
instead of making them install these header files elsewhere.
_Especially_ in the context of a beta release: we can make a different
decision prior to 1.0, if we can’t address the license issue
sufficiently/get Nordic to relicense these header files in time.
Sterling
(*) The header file licenses, in the case of both Atmel and Nordic,
simply state that this source code can only be used in conjunction with
a product that runs on their hardware platform. It is otherwise a
3-clause BSD license. The source code in question, is driver and header
files for their platform: so, it wouldn’t make sense to use it any
other way.
I’m not advocating these clauses, but I think from a user perspective,
its not exactly going to restrict use / open them up to risk. As they
will only be using this source on a nordic platform.
On 10 Nov 2016, at 2:18, Kevin Townsend wrote:
> We have a similar problem with Nordic code where due to older
> restrictive license terms we can't release the source for some
> projects. The terms have gotten friendlier with time, but the earliest
> stuff was quite restrictive.
>
> I'd suggest getting in touch with Nordic, though. They're probably
> open to making some changes in certain situations. If you need a
> contact there, just send me a private email but I know Sterling
> already knows a mutual contact that would be a good person to explain
> the issue to and hopefully get the ball rolling on what will ideally
> lead to compatible license terms(???). It seems like it would be in
> their interest and most of this code isn't useful on anything other
> than their own silicon anyway.
>
> On 10/11/16 02:12, Christopher Collins wrote:
>> Hi Justin,
>>
>> On Thu, Nov 10, 2016 at 08:33:54AM +1100, Justin Mclean wrote:
>>> Hi,
>>>
>>>> The first clause, Grant of License, seems to be problematic:
>>> Look like it "non-sub licensable” may be an issue? And "solely in
>>> connection with a Nordic Integrated Circuit” reads like a field of
>>> use
>>> restriction to me [1]
>>>
>>> Section 4 of the license re distribution may also be a concern.
>> That was indeed my fear. Thanks for calling attention to section 4
>> as
>> well.
>>
>>> Their modified BSD license also may be an issue as it also looks to
>>> includes a field of use restriction.
>> You are right - I hadn't noticed that. However, the fourth clause
>> is missing in the actual commits that were made to address this
>> ticket
>> (https://github.com/ARMmbed/ble-nrf51822/commit/6d1bf116e156b870099694f0ce27076c236c4f44).
>> Maybe there was some additional communication between the mbed team
>> and Nordic that let to the actual changes.
>>
>>> I assume this is optional in that not everyone would need to use it?
>> Yes, these files are optional in the sense that Mynewt can still be
>> used without them. However, someone wishing to use Mynewt with a
>> Nordic
>> MCU will probably won't get very far without them.
>>
>>> 1. https://www.apache.org/legal/resolved#category-x
>> Thanks, Chris
>
Re: Nordic SDK license not Apache-compatible?
Posted by Kevin Townsend <ke...@adafruit.com>.
We have a similar problem with Nordic code where due to older
restrictive license terms we can't release the source for some projects.
The terms have gotten friendlier with time, but the earliest stuff was
quite restrictive.
I'd suggest getting in touch with Nordic, though. They're probably open
to making some changes in certain situations. If you need a contact
there, just send me a private email but I know Sterling already knows a
mutual contact that would be a good person to explain the issue to and
hopefully get the ball rolling on what will ideally lead to compatible
license terms(???). It seems like it would be in their interest and most
of this code isn't useful on anything other than their own silicon anyway.
On 10/11/16 02:12, Christopher Collins wrote:
> Hi Justin,
>
> On Thu, Nov 10, 2016 at 08:33:54AM +1100, Justin Mclean wrote:
>> Hi,
>>
>>> The first clause, Grant of License, seems to be problematic:
>> Look like it "non-sub licensable\u201d may be an issue? And "solely in
>> connection with a Nordic Integrated Circuit\u201d reads like a field of use
>> restriction to me [1]
>>
>> Section 4 of the license re distribution may also be a concern.
> That was indeed my fear. Thanks for calling attention to section 4 as
> well.
>
>> Their modified BSD license also may be an issue as it also looks to
>> includes a field of use restriction.
> You are right - I hadn't noticed that. However, the fourth clause
> is missing in the actual commits that were made to address this ticket
> (https://github.com/ARMmbed/ble-nrf51822/commit/6d1bf116e156b870099694f0ce27076c236c4f44). Maybe there was some additional communication between the mbed team and Nordic that let to the actual changes.
>
>> I assume this is optional in that not everyone would need to use it?
> Yes, these files are optional in the sense that Mynewt can still be
> used without them. However, someone wishing to use Mynewt with a Nordic
> MCU will probably won't get very far without them.
>
>> 1. https://www.apache.org/legal/resolved#category-x
> Thanks, Chris
Re: Nordic SDK license not Apache-compatible?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Yes, these files are optional in the sense that Mynewt can still be
> used without them. However, someone wishing to use Mynewt with a Nordic
> MCU will probably won't get very far without them.
As it optional (not everyone will use it on this platform) it is possible to have a dependancy on it but the code can’t be in our repo and we can’t distribute it.
We can provide instruction on how to do so - but I assuming all of this is less ideal I assume.
Another option would be to contact them and ask for it to be relicensed.
Thanks,
Justin
Re: Nordic SDK license not Apache-compatible?
Posted by Christopher Collins <cc...@apache.org>.
Hi Justin,
On Thu, Nov 10, 2016 at 08:33:54AM +1100, Justin Mclean wrote:
> Hi,
>
> > The first clause, Grant of License, seems to be problematic:
>
> Look like it "non-sub licensable\u201d may be an issue? And "solely in
> connection with a Nordic Integrated Circuit\u201d reads like a field of use
> restriction to me [1]
>
> Section 4 of the license re distribution may also be a concern.
That was indeed my fear. Thanks for calling attention to section 4 as
well.
> Their modified BSD license also may be an issue as it also looks to
> includes a field of use restriction.
You are right - I hadn't noticed that. However, the fourth clause
is missing in the actual commits that were made to address this ticket
(https://github.com/ARMmbed/ble-nrf51822/commit/6d1bf116e156b870099694f0ce27076c236c4f44). Maybe there was some additional communication between the mbed team and Nordic that let to the actual changes.
> I assume this is optional in that not everyone would need to use it?
Yes, these files are optional in the sense that Mynewt can still be
used without them. However, someone wishing to use Mynewt with a Nordic
MCU will probably won't get very far without them.
> 1. https://www.apache.org/legal/resolved#category-x
Thanks, Chris
Re: Nordic SDK license not Apache-compatible?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The first clause, Grant of License, seems to be problematic:
Look like it "non-sub licensable” may be an issue? And "solely in connection with a Nordic Integrated Circuit” reads like a field of use restriction to me [1]
Section 4 of the license re distribution may also be a concern.
Their modified BSD license also may be an issue as it also looks to includes a field of use restriction.
I assume this is optional in that not everyone would need to use it?
Thanks,
Justin
1. https://www.apache.org/legal/resolved#category-x