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’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
> >
