Re: [Hamlib-stationserver] Updated Requirements Doc

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

A few thoughts.

First off, nicely done, Art.

Regarding licensing of future source code.  I have long been in the
GPL/LGPL camp so that is my perspective.  So far we have had good
experience with the LGPL 2.1 for Hamlib.  As Hamlib is a library that
clients link to, either dynamically or statically, certain legal issues
come into play (I'm no expert and will defer to Bruce Perens or the Free
Software Foundation (FSF)).  Using the LGPL draws the "viral" nature of
the GPL at the line of linking to the published API.  This allows
clients with licensing incompatible to the standard GPL to still use
Hamlib.  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.

Conversely, the utilities included in Hamlib ((rig|rot)ctl[d]) are
licensed under the GPL 2.0, for all that entails.

The FSF also offers the Affero GPL for network servers.  I have not ever
investigated it deeply and as Station Server will likely be its own
program/project separate and distinct from Hamlib at some future date,
it needs to have its source code licensed in the manner that is best for
it (I think there is probably unanimous agreement on that point).

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.  I like the LGPL as it
doesn't dictate terms to downstream clients while dictating terms to
everyone equally for the actual source code of the project.  My quick
glance is that the AGPL is much like the LGPL as I have no care how
clients communicating to SS over a network interface are licensed.

I think we should request Bruce's input on this matter.


Regarding points F-3, F-4, F-7, and N-3, authentication, passwords, and
encryption.

Perhaps it is my inexperience of working with these security blocks that
forms my thoughts.  I'm not sure that Station Server should be concerned
with handling those protocols internally.  Working well with secure
tunnels and providing documentation for doing so seems like it would
relieve the project of a lot of concerns.  There is a lot on our plate
already just dealing with the core functionality of the project (I've
already got five gazillion passwords to deal with, I don't think I want
to have to enter one each time I fire up the logger).  I can be
convinced otherwise on this matter, however.


Those are my main thoughts on where we are at the moment.  Everything
else looks like a good goal.

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