Thread: [Hamlib-stationserver] Updated Requirements Doc
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-stationserver
|
From: Art B. <ac...@in...> - 2014-03-06 15:08:07
|
A small update is online at <http://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/StationServer%20Requirements%20DRAFT%202.pdf/download> I hope everyone who can will take a few minutes to look it over and comment. Thanks! - Art KD6O |
|
From: Nate B. <n0...@n0...> - 2014-03-06 16:21:29
|
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 |
|
From: Art B. <ac...@in...> - 2014-03-06 22:06:55
|
On Mar 6, 2014, at 8:21 AM, Nate Bargmann <n0...@n0...> wrote: > 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. OK, so how about if we: * Chang F-1 to read "... in response to queries from the client application(s) over a single IP-based Local Area Network." * Change F-2 to read "...to the client(s) both spontaneously and in response to queries from the client over a single IP-based Local Area Network." * Change F-3 to read, "...over a single IP-based Local Area Network." * Change F-4 to read "Enable the user to change settings and activate functions of connected radios and ancillary devices."; * Trim F-6 to just say "Support multiple simultaneous client connections." (dropping the whole business of different user identities and access privileges); * Drop F-7 entirely (no authentication or user identities); * Drop N-3 entirely (no encryption); and, * Add a note stating that "Users in order to maintain the required control of Amateur Radio stations by a licensed operator, remote StationServer conenctions across multiple networks or the Internet should be implemented using a Virtual Private Network or some other scheme for encryption and secure routing." - Art KD6O |
|
From: Tony L. <vk...@gm...> - 2014-03-06 23:35:12
|
On 7/03/2014 9:06 AM, Art Botterell wrote: > OK, so how about if we: > > * Chang F-1 to read "... in response to queries from the client application(s) over a single IP-based Local Area Network." > > * Change F-2 to read "...to the client(s) both spontaneously and in response to queries from the client over a single IP-based Local Area Network." > > * Change F-3 to read, "...over a single IP-based Local Area Network." > > * Change F-4 to read "Enable the user to change settings and activate functions of connected radios and ancillary devices."; > > * Trim F-6 to just say "Support multiple simultaneous client connections." (dropping the whole business of different user identities and access privileges); > > * Drop F-7 entirely (no authentication or user identities); > > * Drop N-3 entirely (no encryption); and, > > * Add a note stating that "Users in order to maintain the required control of Amateur Radio stations by a licensed operator, remote StationServer conenctions across multiple networks or the Internet should be implemented using a Virtual Private Network or some other scheme for encryption and secure routing." OK, this one works for me. |
|
From: Art B. <ac...@in...> - 2014-03-06 17:43:37
|
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. |
|
From: Nate B. <n0...@n0...> - 2014-03-06 18:58:49
|
* 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 |
|
From: Tony L. <vk...@gm...> - 2014-03-06 22:15:55
|
On 7/03/2014 2:07 AM, Art Botterell wrote: > A small update is online at <http://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/StationServer%20Requirements%20DRAFT%202.pdf/download> > > I hope everyone who can will take a few minutes to look it over and comment. The thing that caught my eye here was the reference to multiple users. I don't believe it's the job of Stationserver to handle multiple users. I envisaged it as a single user system, with multiple user capabilities being provided by an add-on, such as a remote base add-on, which would handle all the multiple user requirements such as authentication and access control. Thinking again though, there may be a use for a (very basic) user authentication mechanism. The question is whether this is best implemented by default (which would be a nuisance for a single user shack, and especially annoying in the case of someone who runs clients and servers on the one PC - though localhost could always be given permission), as an optional switch or as an add-on. I'm somewhere between not having multiuser capability in the core product or having it available via a configuration option, and only a basic set of access controls at this level. One of the assumptions here is that one entity still manages the entire system - whether that be an individual or a club, and there is a reasonable expectation of a degree of trust and personal knowledge of the users (i.e. regularly in face to face contact and can be personally validated). If this trust isn't there, then we have a remote base situation. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
|
From: Art B. <ac...@in...> - 2014-03-06 22:21:35
|
Oops, Tony, our notes passed each other in the mail. Anyway, your note accurately describes at least on aspect of the dilemma, but I'm not sure what you're recommending. Maybe some other folks on the list would like to add some additional perspectives. - Art KD6O On Mar 6, 2014, at 2:15 PM, Tony Langdon <vk...@gm...> wrote: > On 7/03/2014 2:07 AM, Art Botterell wrote: >> A small update is online at <http://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/StationServer%20Requirements%20DRAFT%202.pdf/download> >> >> I hope everyone who can will take a few minutes to look it over and comment. > The thing that caught my eye here was the reference to multiple users. > I don't believe it's the job of Stationserver to handle multiple users. > I envisaged it as a single user system, with multiple user capabilities > being provided by an add-on, such as a remote base add-on, which would > handle all the multiple user requirements such as authentication and > access control. > > Thinking again though, there may be a use for a (very basic) user > authentication mechanism. The question is whether this is best > implemented by default (which would be a nuisance for a single user > shack, and especially annoying in the case of someone who runs clients > and servers on the one PC - though localhost could always be given > permission), as an optional switch or as an add-on. > > I'm somewhere between not having multiuser capability in the core > product or having it available via a configuration option, and only a > basic set of access controls at this level. One of the assumptions here > is that one entity still manages the entire system - whether that be an > individual or a club, and there is a reasonable expectation of a degree > of trust and personal knowledge of the users (i.e. regularly in face to > face contact and can be personally validated). If this trust isn't > there, then we have a remote base situation. > > -- > 73 de Tony VK3JED/VK3IRL > http://vkradio.com > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Hamlib-stationserver mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-stationserver |
|
From: Tony L. <vk...@gm...> - 2014-03-06 23:24:57
|
On 7/03/2014 9:21 AM, Art Botterell wrote: > Oops, Tony, our notes passed each other in the mail. Anyway, your note accurately describes at least on aspect of the dilemma, but I'm not sure what you're recommending. > > Maybe some other folks on the list would like to add some additional perspectives. As I said, I'm undecided. My original vision was for the core system to be focused on network aware rig abstraction, and not deal with users and authentication, and have those who need such facilities install an add-on module to offer these facilities (i.e. a remote base scenario). I was just thinking out loud and could see where you're coming from Art, and I could see scenarios where an entity (most typically a club, but could be friends) might offer hams remote access to their station on a different level to that offered by a remote base (might be an issue for data modes). However, thinking again, a well written remote base add-on might still fit the bill better, and offer a full range of user management and access control capabilities, so I'm leaning back towards no access control in the core of Stationserver (i.e. your latest revision to the specs). -- 73 de Tony VK3JED/VK3IRL http://vkradio.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X