[TangerineSDR] Tangerine licensing

Engelke, Bill bill.engelke at ua.edu
Tue Apr 7 11:17:38 EDT 2020


To all - I request that UA be kept in the loop on these discussions. I personally don't have the authority to make binding decisions on the part of UA, but I can make sure that the right people are involved. For the record, I believe (and will advocate for) that all software should be open source and freely available for re-use same as the code developed by John Melton and Pavel Demin. (Will GPL accomplish that?)  Based on my past experience, since the project has NSF funding, I believe the software becomes public domain (someone might want to clarify that)...   -73- Bill AB4EJ

-----Original Message-----
From: TangerineSDR <tangerinesdr-bounces at lists.tapr.org> On Behalf Of John Ackermann N8UR via TangerineSDR
Sent: Tuesday, April 7, 2020 10:05 AM
To: Dr. Nathaniel A. Frissell Ph.D. via TangerineSDR <tangerinesdr at lists.tapr.org>; Scott Cowling <scotty at tonks.com>; Steven Bible <steven.bible at gmail.com>
Cc: John Ackermann N8UR <jra at febo.com>
Subject: Re: [TangerineSDR] Tangerine licensing

Just to Nathaniel, SteveB, Scotty --

We probably should have a conversation about licensing for the PSWS project to get this settled.  Much, much better to do it sooner rather than later.

73,
John
----

On 4/7/20 8:30 AM, Dr. Nathaniel A. Frissell Ph.D. via TangerineSDR wrote:
> 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
> 


-- 
TangerineSDR mailing list
TangerineSDR at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org


More information about the TangerineSDR mailing list