Re: [Hamlib-stationserver] Licensing (was Re: Updated Requirements Doc)

[Nate B. <n0...@n0...>]

* On 2014 06 Mar 11:46 -0600, Art Botterell wrote:
> In a separate conversation with Bruce last week he mentioned... and
> from my experience I certainly agree... that rightly or wrongly the
> letters "GPL" are something of a poison pill as far as some potential
> commercial adopters are concerned.  

Yes, this is true

> For what it's worth, we went through all this last year at Carnegie
> Mellon Silicon Valley... the University preferred the permissive MIT
> or Mod-BSD licenses for a variety of reasons, one of which was that
> they relieved the copyright holder of any need to monitor or litigate
> with (or on behalf of) adopters in the future.

Now that is a point that in all the years of commentary over licenses I
do not recall being argued by the arm chair attorneys.  My initial
reaction is that it is inded valid, and may well be the most valid point
for using the more permissive license.

> > Conversely, the utilities included in Hamlib ((rig|rot)ctl[d]) are
> > licensed under the GPL 2.0, for all that entails.
> 
> Which is arguably slightly less that totally Libre, in that it
> prohibits incorporating the code into a differently-licensed
> derivative.  (Indeed, we might be in that box now ourselves, depending
> on how we integrate hamlib moving forward.)  

So long as the C API is used, no issue.  I favor the track that Hamlib
is a short term solution to have access to a lot of radio definitions.
As a native definition method matured the reliance on Hamlib should
disappear.

> Such a restriction might be ideologically correct, but it puts a hurt
> on some folks' business models.  The risk is that in hopes of keeping
> the software rigorously "open" we might inadvertently drive it into an
> evolutionary dead-end.

I'm not too worried about this unless it is probable that our
implementation would be incorporated directly into some
product/software.  I suppose it could happen.

> > The MIT/BSD license was mentioned early on and I honestly do have a
> > bit of heartache about that.  Perhaps some of that is unfounded.  I
> > have always likened those licenses to "throwing it over the wall"
> > where anyone can pick up one's work and run with it in any direction
> > with little obligation other than the license notice.  
> 
> Perhaps you could expand a bit on what you see as being wrong with
> that?

Probably just my perspective due to my leaning more toward the FSF/GPL
stance.

> Personally, my only concern is to make sure nobody can charge rents or
> obstruct progress by taking our code hostage and restricting others'
> freedom to use it and build on it.  And of course attribution is nice
> for the reputation value.

I recall the famous, "Embrace, Extend, Extinguish" meme.  To be fair, I
don't think that would be much of a threat in the ham radio software
space.

> But do I actually plan to spend the rest of my life monitoring and
> litigating over this stuff?  Naah... life's too short and technology
> advances too rapidly.*  Document the prior art and move on!
> 
> But that's just me. ;-)
> 
> - Art KD6O
> 
> * Actually... from an interoperability and public-benefit perspective
> I've come to the conclusion that open interface standards and
> protocols are more important and much more durable than open code.
> Hardware platforms and software frameworks have a relatively short
> half-life.  It's the interface standards that tend to persist, and
> they're what enables future technology evolution (the archetypical
> example being the Internet Protocols.)   But again, that's just my
> opinion.

I'm in full agreement.

There is the saying, "The authors choose the license."  I doubt I will
contribute much code, so the MIT/BSD license is acceptable to me.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us