[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