On Thu, 29 Sep 2011 12:17:45 +0000 David Moisan <dmoi...@davidmoisan.org> wrote:
> 1) Depending on the problem domain, "thousands of eyes", could be just > "hundreds of eyes" or even "tens of eyes". And that is only if these eyes > are able to take the time to look at the code. That can be the hardest thing > to do unless you are very experienced and can see the bug jump right out at > you through intuition. There have been a number of security bugs in open > source code that have been only found years later. But they *have* been found. Who knows how many defects in closed-source OSes are out there, with viable exploits? Some eastern european guy, possibly, with a massive botnet. You? Me? Not bloody likely. > 2) I said problem domain in my first point, and that can mean rig control. > Or framework design, libraries or even lower-level drivers. We don't know > what code Simon has used under license, but if it is only just rig control, I > would be very surprised. More likely, it is the framework he used and the > terms he had to use it under. That is a very important decision that a > developer must make early on. Usually, developers just use what's "out of > the box", like .NET or another common framework like Qt. That can affect > everything, including the licensing. Everything. Clearly if the absolute core of the OS is under some licence fundamentally incompatible with any OSI licence, then the whole gig is a failure from the start. Oh well, no matter. These things happen. > 3) The GPL that many people advocate is a viral license. By itself, the GPL > requires that if you change the code, you have to publish it. Plus all the > other parts, which can include libraries, at least in some interpretations. > Other licenses like the BSD or the LGPL don't have this condition, but they > also don't require (by themselves) that the changed code be public. Some > code repositories, like Codeplex, will not allow GPL'd code for this reason. > There's been much controversy over the use of such code in libraries and > whether the license terms apply to the main code that calls them. Ah, the "viral licence" story. I wondered when that was coming out! You do realise that by using Microsoft's libraries and development tools for (for example) C#, you have to hand over the rights to your code to them? Check the EULA carefully - if Microsoft say they want it, you have to hand it over or you are no longer licensed to use their stuff. You have to be *so* careful with these things. There's nothing to stop you dual-licensing code, even if one of those licences is the GPL. > 4) If you get through these points and you do change the code, no one is > obligated to accept your changes. Going back to my first point, of all the > users and potential developers that can see the source code, there are > historically only a small number of those that propose, and commit, code > changes. Sometimes, if there is a dispute between factions on a project, the > code gets "forked". Imagine seeing HB9DRV and HB9DRV-2, though it would > probably be called HRD and "HR Super Betterer Deluxe" or something like that > :) . That can be a bad thing to happen, particularly in a small community > like ours. I believe this, and other related issues, have crippled Linux > badly enough to affect its long-term future. "Crippled", eh? I'm sure you can give some good examples, too. > The best chance that the group holding HRD would have towards the goals of > open source, or at least what most people here seem to be asking for, would > be to publish an API (Application Programming Interface) and ABI (Application > Binary Interface) to its control interface. That limits the scope of the > developer, but makes it much more likely for him or her to succeed. In other > words, publish the specifications of the rig control interface. That is > still a big job not to be underestimated. But it is much more feasible, and > it may lead to a genuine standard in our field. Is there really any point in doing that? As I've said in previous posts, controlling radios is a solved problem. You *do not need* to reinvent that particular wheel yet again. It's been invented, we have one, it's called hamlib, and it works. No, the rig control interface is the least of the problems. The messy and incomprehensible UI needs work first. -- Gordon JC Pearce MM0YEQ <gordon...@gjcp.net> _______________________________________________ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
