[TangerineSDR] Tangerine licensing

[Dr. Nathaniel A. Frissell Ph.D.]

Hi John,

Is it possible to start with GPL and then relicense as BSD if needed? I think this gives us the most protection now, and opens the possibility for wider adoption in the future.

73 de Nathaniel W2NAF

— 
Dr. Nathaniel A. Frissell, Ph.D., W2NAF
HamSCI Lead
Assistant Professor
Department of Physics and Electrical Engineering
University of Scranton
(973) 787-4506

> On Apr 2, 2020, at 11:18 PM, Rob Wiesler via TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
> 
> 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).
> 
> -- 
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org