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
