[TangerineSDR] Tangerine licensing

[Rob Wiesler]

On Thu, Apr 02, 2020 at 11:45:07 -0400, John Ackermann N8UR via TangerineSDR wrote:
> We should formalize the requirements for licensing Tangerine hardware
> and software work product.
>
> For software, I would recommend simply requiring an OSF-approved open
> source license.  We should consider a copyright assignment from
> contributors, as discussed below.  While I'd personally prefer to use
> GPL, that could be an inhibiting factor for some organizations that
> might be involved so I'm comfortable with allowing any OSF license.

We often won't have very much leeway to choose a license.  For instance,
GNU Radio plugins will probably have to be GPLed, as they are derivative
works of GNU Radio.

It's good to note that bounding software components (and their licenses)
tightly makes a lot of licensing issues go away.  For instance, we'll
probably want our GNU Radio-related components to consume input and
publish output in a standardized fashion anyway, but as a side effect,
this means that whatever's on either side of those components won't be a
derived work, meaning it won't have to be GPLed.  And if we do choose to
use the GPL for any components, properly defining the limits of the
license are critical - for instance, it's common to license libraries
under a variant of the GPL that specifically mentions that it's okay to
link against OpenSSL, so that users of the library don't have to choose
between the two libraries (as the GPL is incompatible [0] with the
Apache 1.0 license that OpenSSL used to be licensed under).

By the way, OpenSSL did switch to Apache 2.0, which is compatible with
the GPL (version 3 only) (asymmetrically - see [2]).  They did this
using a Contributer License Agreement [1] (which often involves a
copyright assignment).  It still took them two or three years to
complete the process, because they had to hunt down every single
contributer whose copyrighted code remained in the project and ask them
to switch licenses (just identifying them is often nigh-impossible if
your version control history isn't up to the task).  Then, for everyone
who doesn't respond or refuses, the project had to replace what they
wrote with something written from scratch under the new license.  Having
a Contributer License Agreement means that the project (or a trustee)
holds copyright over everything, or otherwise has been granted the
rights necessary to simply change the license for everything in the
project.

Here's some reading material:

[0] https://en.wikipedia.org/wiki/OpenSSL#Licensing
[1] https://en.wikipedia.org/wiki/Contributor_License_Agreement
[2] https://www.apache.org/licenses/GPL-compatibility.html

Here's a project I've been dealing with recently that has a license
proliferation problem that has personally caused me grief:

[3] https://github.com/u-boot/u-boot/tree/master/Licenses

Here's a handy way to make it possible to determine what a file's
license is in an automated fashion (which is more useful than you'd
think, even when taking into account this statement):

[4] https://spdx.org/using-spdx-license-identifier

As far as a specific license to use (when we can choose), I'm quite
happy with the GPL, but won't complain if a non-reciprocal license is
chosen (for any given software component).  Everything I write at work
is under the BSD 3 Clause license, except where the GPL is required (or
simplifies things).