[TangerineSDR] Tangerine licensing
John Ackermann N8UR
jra at febo.com
Thu Apr 2 19:08:55 EDT 2020
Hi Dave --
That question opens a big door because there are something like 30
approved OSS licenses.
They mainly break down into two categories: "permissive" and "reciprocal".
Permissive licenses basically say you can use the code for anything you
want, and you can make changes without releasing them back to the
community. In other words, a company could take your code, add their
own stuff to it, and then sell the combination as a proprietary product.
The canonical permissive licenses are the BSD and MIT licenses (which
are virtually identical -- BSD is the most commonly used).
Reciprocal licenses basically say that if you make changes to the code,
including adding additional features or capabilities, *and* distribute
the changed code, you have to make the modified source code, including
all your additions, available to anyone who wants it, no questions
asked. The canonical reciprocal license is the GPL, either v2 or v3.
Many companies fear and/or loathe reciprocal licenses because they are
afraid that by using the code they will have to disclose their own
proprietary stuff. That can happen, and it's a valid concern, but there
are a lot of cases where that's not a meaningful risk. But as a result,
many companies have a ban on contributing to or using code that's under
a reciprocal license.
Personally, I favor reciprocal licenses for most of my work, but
sometimes use permissive. For example, we thought the TICC might be
popular with commercial customers and didn't want to scare them away, so
decided to license its firmware under the permissive BSD license.
You can make good arguments to take either approach. My only strong
advice is to pick either BSD or GPL and not use one of the many other
approved licenses, unless you have a really good reason to. Most of the
others just add complication to meet someone's perceived need. I prefer
to keep it simple.
On 4/2/20 12:28 PM, Dave Larsen wrote:
> Are there preferences?
> openhpsdr.org <http://openhpsdr.org> used GPL2 and GPL3 depending on
> the time frame the software was produced.
> There are lots of choices.
> Dave KV0S
> On Thu, Apr 2, 2020 at 10:45 AM John Ackermann N8UR via TangerineSDR
> <tangerinesdr at lists.tapr.org <mailto:tangerinesdr at lists.tapr.org>> wrote:
> This thought was prompted by my other message...
> 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.
> For hardware, I think we've agreed that the TAPR OHL
> (http://tapr.org/OHL) should be used.
> But because of the economics of hardware design and manufacture, the
> implementation is not quite as straigh-forward as for software. The
> problem is that immediately publishing the full design documentation
> with gerbers, etc., could bring on competitors who might undercut the
> market while TAPR is left holding inventory that required significant
> up-front investment (we had first-hand experience with this problem
> several years ago).
> The way TAPR has normally dealt with this issue is to ask each design
> contributor to sign an agreement that says a few things:
> 1. The product will be licensed under OHL.
> 2. TAPR has the exclusive right to produce an initial production run of
> the Product. That right ends __ days after first product shipment.
> 3. Developer may release descriptions, images, and schematics at any
> time, but may not provide Gerbers or other manufacturing documentation
> until after the exclusivity period ends.
> 4. Once the exclusivity period is over, everyone has the right to
> publish full manufacturing documentation.
> 5. Developer assigns his/her IP rights in the design to TAPR, and TAPR
> gives back a very broad license that pretty much allows the developer to
> do whatever they want except outright sell the IP. This is similar to
> what the FSF does with individual contributors to its software projects;
> it gets the project rights in one place to make potential negotiations
> easier (e.g., offering products under a dual-license structure).
> A copy of an agreement to accomplish that is attached. I'd welcome any
> thoughts about this approach, but it is something we should close on
> pretty soon.
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org <mailto:TangerineSDR at lists.tapr.org>
> KV0S - Dave Larsen
> Columbia, MO, USA
More information about the TangerineSDR