Source code documentation is coming. We plan to implement some auto-documentation coding standards in order to take advantage of some really nice XML based engines that will turn comments into html documentation. This will come with the new architecture that is currently being revised for the 1.5 Beta branch of the source.
We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Eric Wachsmann FlexRadio Systems -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Lux Sent: Tuesday, August 30, 2005 1:16 PM To: FlexRadioMail Subject: [Flexradio] A plea to SDR software developers A couple pleas to those of you ambitously cranking out great stuff for the SDR, particularly in the Linux world 1) Gosh.. there needs to be SOME documentation of the structure of the software. Even a readme listing that says what each module does and who calls what. Sure.. am_demod.c probably does something with demodulating AM, but you'd never know it from reading the comments. Same applies to the PowerSDR sources... I hunted through the zip file a while, but never found any sort of documentation. Surely you guys have some sketchy document around that has the overall architecture? Maybe it exists, but it would be nice to have a link to where it is. Don't make it too challenging or nobody will get interested. 2) Structure the software so that you can make mods without getting wrapped around the GPL axle. There are people out there who would like to make contributions, and are actually paid to do software development, but for a variety of reasons, can't modify GPL stuff. For example, at Jet Propulsion Lab, most all of our work is funded by NASA, and software that is developed with that funding is notionally available to all, for free (well, the U.S. taxpayers have already paid for it). There's a whole raft of contractual details between CalTech (who runs JPL) and NASA about how that software is to be released, the (not entirely accurate) summary of which is that it has to be released in a different way, and with a different rights statement, that are incompatible with the usual GPL way of doing things. This came up when I wanted to use a modified version of hamlib and rigctl to control the SDR1000. The real problem came up when we wanted to release the modified versions. The GPL requires that modified versions also be GPLd, etc, be distributed in a certain way, etc. We wound up rewriting the needed functions from scratch (which was no big deal, but had I known from the start, I would have done things differently). So, if I want to insert something useful into a body of software that is GPLed, I have to make sure that my little piece is sufficiently standalone and doesn't include any GPL code in it. I can call modules in some library that's GPLd, and I can be called by GPL'd software, but I have to be self contained. This meets the GPL requirement: " If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. " Once it's been released (with the NASA process), you'd be free to include that with the rest of the system. And, in fact, you could freely modify what we developed and released. (you might even be able to GPL the copied/modified version, for all I know) There is also a review process that we have to go through to make sure that we haven't inadvertently trampled on someone else's proprietary rights, and that we aren't violating export controls, etc. There's a whole team of folks who deal with this stuff. I suspect other companies have similar issues. They may have no problem with releasing software that they've paid to develop into free distribution, but can't tolerate some aspect of the GPL. So.. when structuring your software, make sure you do it in a way that allows other parties to hook into it, without requiring too tightly tying it to the rest. Giant include files that define the world are "bad" from this standpoint. Shared memory structures likewise. Clean procedure call interfaces with relatively simple data structures as parameters or socket level comms, with a well defined protocol, are good. And, keep those data and message structures reasonably stable, because I can't use the GPLed .h file to define them. I have to create my own version that replicates it. (or, alternately, release the .h file into the public domain, explicitly) James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875 _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
