[TangerineSDR] Tangerine licensing

Tue Apr 7 10:23:26 EDT 2020

Hi Nathaniel --

We certainly could do so.  However, any kind of relicensing (or dual
licensing) is pretty much impossible unless the copyright is held by one
person/entity -- otherwise you need to get approval from each and every
contributor which can be difficult to manage.

The way FSF and other groups handle that is by having contributors sign
an agreement assigning their IP rights to the organization.  If that's
done, then the organization has the ability to change the licensing if
desired.

That's why I suggested something like the Project Funding Agreement I
sent around because it includes that assignment.  However, that document
is focused more on hardware where the assumption is that the contributor
is getting financial support for prototypes, etc.  In the case of pure
software development that's not usually a factor.

It's easy enough to broaden and rename that agreement to cover both
hardware and software regardless of funding, and I can do that.

The real question is whether there should be an official policy that all
hardware/software contributors need to sign an assibnment agreement, and
secondarily who the assignment is to (particularly if HamSci is not a
legal entity).

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
> 