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

[Art B. <ac...@in...>]

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.  

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.

> Our philosphy for the library has been that we don't wish to
> dictate terms beyond that of assuring that the library source code
> remain Free (Libre) Software.

Exactly... 

> 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.)  

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. 

> 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?   

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.  

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.