You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Gregory Nutt <sp...@gmail.com> on 2020/01/17 14:44:32 UTC
SocketCAN License
I have been having an offline discussion with a business that is
interested in bringing VW's SocketCAN into NuttX. But I am puzzled by
how the licensing fits with Apache. Let me just quote:
/I’m no legal expert but Volkswagen research dual licensed SocketCAN
as Dual BSD/GPL as shown in
//https://github.com/torvalds/linux/blob/master/net/can/af_can.c//at
line 1 and 69./
/Does this mean we can reuse the Linux Volkswagen research SocketCAN
code in Apache NuttX?/
At that reference, you see the files starts with an extra line:
// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
/* af_can.c - Protocol family CAN core module
* (used by different CAN protocol modules)
*
* Copyright (c) 2002-2017 Volkswagen Group Electronic Research
* All rights reserved.
and is followed by a standard 3-clause BSD license. This code is from
VW, but is part of Linux. If sourced from Linux, I presume that the
code would be GPLv3? Is that true? I really don't know.
So I think there are three questions: (1) Can we re-use such dual
licensed software, (2) if so, de we need to get the code from a source
other than Linux, and (3) would any special grants or permissions be
required from VW?
Greg
Re: SocketCAN License
Posted by Rob Voisey <ro...@fenconsultants.com>.
My approach has always been to go direct to the copyright holder and get it
in writing that you can use the code under a license which is compatible
with yours. It makes things a lot simpler down the line, even if it's
usually a massive hassle up front.
Rob
On Fri, 17 Jan 2020, 14:44 Gregory Nutt, <sp...@gmail.com> wrote:
> I have been having an offline discussion with a business that is
> interested in bringing VW's SocketCAN into NuttX. But I am puzzled by
> how the licensing fits with Apache. Let me just quote:
>
> /I’m no legal expert but Volkswagen research dual licensed SocketCAN
> as Dual BSD/GPL as shown in
> //https://github.com/torvalds/linux/blob/master/net/can/af_can.c//at
> line 1 and 69./
>
> /Does this mean we can reuse the Linux Volkswagen research SocketCAN
> code in Apache NuttX?/
>
> At that reference, you see the files starts with an extra line:
>
> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> /* af_can.c - Protocol family CAN core module
> * (used by different CAN protocol modules)
> *
> * Copyright (c) 2002-2017 Volkswagen Group Electronic Research
> * All rights reserved.
>
> and is followed by a standard 3-clause BSD license. This code is from
> VW, but is part of Linux. If sourced from Linux, I presume that the
> code would be GPLv3? Is that true? I really don't know.
>
> So I think there are three questions: (1) Can we re-use such dual
> licensed software, (2) if so, de we need to get the code from a source
> other than Linux, and (3) would any special grants or permissions be
> required from VW?
>
> Greg
>
>
>
Re: SocketCAN License
Posted by Gregory Nutt <sp...@gmail.com>.
> So assuming all the code is dual licensed GPL/BSD and not a mixture of licenses then we’re fine to use it. We would need to note its license in our LICENSE file.
Great! So I am proposing to assist the parties that are interested in
the development by creating a SocketCAN branch and contributing the
basic socket layer support. I would ask them to contribute the ported
SocketCAN implementation in a form compatible with the NuttX network
architecture, compatible with the NuttX coding standard, and fully
verified. There are several parties involved here and I don't know who,
if anyone, has committed to the implementation: NXP, PX4, UAVCAN, VW,
all or some of the above. VW is very supportive of this effort they
are the owners of the SocketCAN code so even in the worst case licensing
scenario, I think we should be able to work things out.
We can be careful with the licensing throughout this and we can ask for
a thorough license review before any move to master is considered.
I don't plan to do anything, however, until I have a firm commitment for
the development.
Greg
Re: SocketCAN License
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
A couple of points:
- The GPL license is not compatible with the Apache License and its ASF policy not to include GPL code in our source releases [1][2]
- If things are dual licensed (which means all code is License A or license B rather than a mixture of license A and licenseB) when you can use the more friendly license, so if something is dual license GPL/BSD then you can use it under the BSD terms [3]
- BSD code can be included in an ASF source release [4]
So assuming all the code is dual licensed GPL/BSD and not a mixture of licenses then we’re fine to use it. We would need to note its license in our LICENSE file.
Thanks.
Justin
1. https://www.apache.org/legal/resolved.html#category-x
2. https://www.apache.org/licenses/GPL-compatibility.html
3. https://www.apache.org/legal/resolved.html#mutually-exclusive
4. https://www.apache.org/legal/resolved.html#category-a
Re: SocketCAN License
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Maybe setting up fossology would be a good idea at some point. Does Apache
> run a fossology server?
We don’t but I have suggested before that this project do so.
Thanks,
Justin
Re: SocketCAN License
Posted by Brennan Ashton <ba...@brennanashton.com>.
Yep,
The PR I referenced was cleaning up the spdx headers in that userspace
project so that it was clear how files are licensed. The stuff that
originated from VW is still dual, but a lot of the stuff added later is
only GPL. The good news is most of the core utils fall into the dual
licensed bit. This is also why it would prudent to keep the spdx headers.
If we pull any of the code in.
Maybe setting up fossology would be a good idea at some point. Does Apache
run a fossology server?
--Brennan
On Fri, Jan 17, 2020, 2:26 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> Looking through teh files in that repro I not some are GPL only. e.g [1]
> but files that are dual licensed are fine e.g [2] NuttX releases would not
> be able to include or depend on those files.
>
> Thanks,
> Justin
>
> 1. https://github.com/linux-can/can-utils/blob/master/slcand.c
> 2. https://github.com/linux-can/can-utils/blob/master/canbusload.c
Re: SocketCAN License
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Looking through teh files in that repro I not some are GPL only. e.g [1] but files that are dual licensed are fine e.g [2] NuttX releases would not be able to include or depend on those files.
Thanks,
Justin
1. https://github.com/linux-can/can-utils/blob/master/slcand.c
2. https://github.com/linux-can/can-utils/blob/master/canbusload.c
Re: SocketCAN License
Posted by Gregory Nutt <sp...@gmail.com>.
I got a response from the VW Open Source person, Oliver HartKopp. For
now, I will just forward it as is to the entire list:
-------- Forwarded Message --------
Subject: Re: SocketCAN in NuttX?
Date: Fri, 17 Jan 2020 17:12:30 +0100
From: Oliver Hartkopp <so...@hartkopp.net>
To: Gregory Nutt <sp...@gmail.com>
Hi Gregory,
that's a cool idea and I definitely support your idea to support
SocketCAN for NuttX!
First the GPL version of the Linux kernel is GPL-2.0-only as GPLv3 would
require many things that are hard to fulfill in embedded devices.
The code of SocketCAN is GPLv2/BSDv3 dual license as you can see on top
of the different files, e.g. linux/net/can/af_can.c:
// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
And the reason why I made it a dual license was because of people like you.
Please read the license text e.g. in af_can.c
e.g.
* The provided data structures and external interfaces from this code
* are not restricted to be used by modules with a GPL compatible license.
The code just becomes a GPLv2 code when it is used in a GPLv2 context,
e.g. the Linux kernel.
The idea of having a standard socket interface for CAN is not bound to
Linux but might be used in BSD or even Windows. We had a Windows NT
implementation as proof-of-concept which we didn't publish as there was
no interest on CAN hardware manufacturers side to support the CAN
network interface for their HW - which would have killed their vendor
Lock-in ...
All contributors that contributed to the SocketCAN core should know that
this code is dual licensed.
There are Linux specific interfaces into the kernel to handle socket
buffers (skbs) and other registering stuff which would not work in your
environment.
But the socket API and the CAN specific implementations for filter lists
or using a network-style CAN driver interface could be usable as-is.
IANAL too - but you should make your legal guys checking what happens to
BSD3 code when you want to use it in an ASF context.
Would be great to see the SocketCAN API in other operating systems which
would make it very easy to port CAN applications too.
The can-utils user space tools in
https://github.com/linux-can/can-utils
are dual licensed too - in most of the cases.
For the same reason ;-)
Best regards,
Oliver
On 17/01/2020 16.20, Gregory Nutt wrote:
Hi, Oliver,
I learned about you through the VW site:
https://www.volkswagenag.com/en/news/stories/2019/11/the-open-source-missioner.html#
. My name is Gregory Nutt and I am the creator of the NuttX Embedded RTOS.
I want to discuss with you about using SocketCAN in the NuttX RTOS. I
have had a request from the NXP drone group asking to add support for
SocketCAN in NuttX. NuttX has a nicely layered network and I believe
that the code would drop in very simply. The NXP engineering team are
advocating "lifting" the code from Linux since it has a dual GPLv3,
BSD-3 license. But I think that there could be problems with that.
NuttX very recently became part of the Apache Software Foundation (ASF)
which is very careful with licensing and I think they will object to
that idea (with some good reason). The primary concerns that they would
have would be, I think:
* I think legal would interpret the code in Linux to be under the
GPLv3 license. GPL is, of course, incompatible with the Apache
license and could never come into Apache NuttX. I think they would
want to get the code from another location. Is there a sanitized,
non-Linux implementation available somewhere. I see github.com
repositories, but they appear to be Linux code as well.
* Even to include third party code code with a compatible license, the
ASF would probably require a software grant. The Apache software
grant doesn't mean the VW would be giving the software to NuttX,
only that it is granting the rights to use the software.
I am not an attorney. I have asked for advice from Apache legal, but I
have not yet received that advice. I am just anticipating what they
will say based on past experience.
There is a fairly large number of developers using the existing
character driver CAN in NuttX: ROS2, PX4-based drones, German motorcyle
manufactuers, uavcan, etc. Having SocketCAN in the OS would be a great
enhancement to the RTOS and would extend interest in SocketCAN to a
larger audience.
Looking forward to your response,
Gregory Nutt
Re: SocketCAN License
Posted by Gregory Nutt <sp...@gmail.com>.
> Not legal advice, but this should be fairly clear because they did the leg
> work of doing the spdx headers (which we should keep if we bring this in).
> We can treat the code either the GPLv2 or the BSD-3 license, this actually
> came up recently because the licensing around can-utils was being clarified
> which I had made a small contribution to and they asked for acks on some
> license headers.
>
> https://github.com/linux-can/can-utils/pull/143
>
> Note that there is a mix and not all of the spdx headers include the BSD
> license option.
>
> How this relates to the move to the Apache 2.0 I'm not sure on. Probably
> can email Apache Legal.
I did run across this which provides the Linux interpretation of dual
licensed code:
https://www.kernel.org/doc/html/latest/process/license-rules.html
Reading licenses is like breathing chloroform; after a few paragraphs,
my eyes roll back in my head and I begin drooling on myself. But I
think the dual licensing is okay from the standpoint of Linux:
https://www.kernel.org/doc/html/latest/process/license-rules.html
I am sure Apache has a stronger position
Greg
Re: SocketCAN License
Posted by Brennan Ashton <ba...@brennanashton.com>.
Not legal advice, but this should be fairly clear because they did the leg
work of doing the spdx headers (which we should keep if we bring this in).
We can treat the code either the GPLv2 or the BSD-3 license, this actually
came up recently because the licensing around can-utils was being clarified
which I had made a small contribution to and they asked for acks on some
license headers.
https://github.com/linux-can/can-utils/pull/143
Note that there is a mix and not all of the spdx headers include the BSD
license option.
How this relates to the move to the Apache 2.0 I'm not sure on. Probably
can email Apache Legal.
--Brennan
On Fri, Jan 17, 2020, 6:44 AM Gregory Nutt <sp...@gmail.com> wrote:
> I have been having an offline discussion with a business that is
> interested in bringing VW's SocketCAN into NuttX. But I am puzzled by
> how the licensing fits with Apache. Let me just quote:
>
> /I’m no legal expert but Volkswagen research dual licensed SocketCAN
> as Dual BSD/GPL as shown in
> //https://github.com/torvalds/linux/blob/master/net/can/af_can.c//at
> line 1 and 69./
>
> /Does this mean we can reuse the Linux Volkswagen research SocketCAN
> code in Apache NuttX?/
>
> At that reference, you see the files starts with an extra line:
>
> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> /* af_can.c - Protocol family CAN core module
> * (used by different CAN protocol modules)
> *
> * Copyright (c) 2002-2017 Volkswagen Group Electronic Research
> * All rights reserved.
>
> and is followed by a standard 3-clause BSD license. This code is from
> VW, but is part of Linux. If sourced from Linux, I presume that the
> code would be GPLv3? Is that true? I really don't know.
>
> So I think there are three questions: (1) Can we re-use such dual
> licensed software, (2) if so, de we need to get the code from a source
> other than Linux, and (3) would any special grants or permissions be
> required from VW?
>
> Greg
>
>
>