At 12:46 PM 8/30/2005, KY1K wrote:
Hey guys...........
I'm not a programmer, never have been and never will. I don't understand
2/3rds of the terms used in the original message. But, I know the hardware
and the concept of the QSD and that software is needed to make it
run.......hardware implementations become quite complex for a variety of
reasons.
The SDR-1000 page makes a very big deal about being flexible and the
source code being available.
Software is the heart of the SDR. While I can't speak as a software
person, I can speak with great authority as a potential purchaser of the
SDR-1000. If there is a problem with distribution or with anything that
affects the ability of third parties to add features in software, I think
the customers have a right to know this BEFORE they buy.
Maybe this matter needs more public exposure.
As a potential customer who wants one of these units, I think I have the
right to know if the source code isn't 'available' (as it's advertised to
be). Is this a topic that should be further explored by the ARRL before
they publish the third Product Review of the SDR-1000 (scheduled for
publication in June 2006)?
The source code IS available (right on the http://www.flex-radio.com/
website) . And it's available under the Gnu General Public License. That
license (in partial summary) essentially says that if you modify it *AND*
redistribute the modified version, that the license has to continue with
the modified version.
You can't, for instance, take PowerSDR, add a bunch of nifty features
throughout, call it (for example) "LuxSuperSDR" and sell it (or give it
away) with a license that doesn't let people make copies or imposes other
restrictions that the original PowerSDR GPL didn't.
If you want to modify it for your own use (and not redistribute), you can
do whatever you darn well please in the privacy of your own home, as far as
GPL is concerned.
If you're happy with GPL and it's terms (most folks are.. I certainly am),
then for work you do for yourself, you're in great shape. The hiccup comes
when someone else is paying for the work and THEY aren't happy with GPL.
One scenario where this is the case is the one I outlined in my original
post: JPL has problems with distribution of GPLed software because it
doesn't match their NASA contractual requirements, which also require them
to distribute software developed with taxpayer money. (This IS being dealt
with, by the way, but "The gears of the law grind slow and exceedingly
fine"...)
The other scenario is where a third party vendor wants to add
functionality, but for some reason, needs to keep a proprietary
component. I give a lengthy example below.
My plea was to make sure that the software architecture is built in a way
that lets me add something to it in a way that's separate from the GPLed
software, and that I could do my thing without having to modify the GPL
software.
Here's a practical example.. Say you wanted the the PowerSDR software to
control your antenna rotator. The rotator manufacturer supplies a program
that controls their rotator, but it's proprietary. You'd click on some menu
option, and PowerSDR would just fire off a command to that program
(something like "LuxRotate 137" would point the antenna to 137 degrees).
It might well be that Lux Rotator company isn't interested in releasing the
details of their proprietary computer to rotator interface. Lux Rotator is
a hardware company, making money selling rotators... they have no interest
in producing super duper software, BUT, they do want to keep people from
making knockoff rotators. However, they might be willing to license it to
another company who wants to create a program that will translate call
signs off DXCluster into lat/lon and then into heading.
So, they license the control protocol to Art's Software Mill, who then
creates a new program called OwlRotate. Lux Rotator, though, requires Art
to keep that protocol secret, which means that Art cannot distribute source
code (since that would reveal the command protocol). Hopefully, you could
configure some file in PowerSDR that would fire off "OwlRotate W6RMK" and
life would be good. Art's Software Mill can then sell their OwlRotate
program happily, complying with their agreement with Lux Rotator. And,
PowerSDR stays totally open and GPLed, because NO modifications were made
to PowerSDR.
You can do this integration at a somewhat finer level (i.e. rather than a
standalone program that gets called, maybe it's a library routine that gets
called, or compiled in).
However, IF the architecture of PowerSDR (or dttsp) is incorrectly
formulated, then it might not be possible to do this. Maybe PowerSDR
requires the program names and syntax to be compiled into the code, so that
changing from LuxRotate to OwlRotate requires modifying PowerSDR. Then,
Art's Software Mill is faced with trying to do two things.. distributing a
modified (GPLed) version of PowerSDR (as source, because GPL requires it)
and their proprietary (no source available) OwlRotate program. Then, what
happens if a Art decides it's not worth it to keep updating the modified
version.
You wind up with a horrible compatibility nightmare:
Art does all this GPLing stuff, and distributes a modified version of
PowerSDR 1.2 (call it OwlSoftPowerSDR) that will fire off OwlRotate.
Several years later, FlexRadio is distributing and supporting version 2.3
of Power SDR, which does NOT support OwlRotate. Art is still distributing
version 1.2 with OwlSoft mods, which does support OwlRotate. Because Art
actually hired Bob, an ambitious undergrad, during the summer, to do his
coding, and Bob has graduated, gotten married and moved to Lower Elbonia,
even Art wanted to produce a revised version of PowerSDR, based on the
latest release, he couldn't.
Note that this is not sent to the reflector or any other public domain
newsgroup or mailing list.
Art
Jim, W6RMK
