[TangerineSDR] Tangerine licensing

John Ackermann N8UR jra at febo.com
Tue Apr 7 11:04:44 EDT 2020


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
> 




More information about the TangerineSDR mailing list