Greetings, all!
I've recently been bitten by the rtlsdr bug and have since developed some software around it. It's Windows-based and currently decodes (mono) WFM, NFM, POCSAG, FLEX 1600/6400, and (very limited) AX.25 frames.
I would like to make a semi-limited release but have some concerns about the licensing of the rtlsdr library after what SDR# went through (or seemed to go through--I'm not sure what the whole story was). I do plan on open-sourcing the whole thing eventually, but in the short term I'll probably have a limited read-only license.
Simply put, am I in the clear if I: - only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and rtl-sdr_export.h - do not distribute the binary rtlsdr.dll, but instead link to the Osmocom binaries
Thanks for the help!
- Scott
Do you have suggestions, then, as to the approach I should take? I plan on using a GPL-compatible license eventually, but the code isn't ready for that yet, and I'd like to head off any licensing issues in advance. What about interfacing only with ExtIO? So far, I have avoided that option because I've only had access to rtlsdr devices.
Thanks for any help!
- Scott
On Tue, Sep 25, 2012 at 9:17 PM, Sylvain Munaut 246tnt@gmail.com wrote:
Hi,
Simply put, am I in the clear if I:
- only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and
rtl-sdr_export.h
- do not distribute the binary rtlsdr.dll, but instead link to the
Osmocom
binaries
Simply put: No.
Cheers,
Sylvain
On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler scott@scottcutler.net wrote:
Do you have suggestions, then, as to the approach I should take? I plan on using a GPL-compatible license eventually, but the code isn't ready for that yet, and I'd like to head off any licensing issues in advance. What about interfacing only with ExtIO? So far, I have avoided that option because I've only had access to rtlsdr devices.
ExtIO would be acceptable if you don't distribute it bundled with it.
rtl_tcp is the completely isolated way.
Cheers,
Sylvain
PS: Of course this does not constitute legal advice and only represent my personal opinion and I don't represent all the copyright owners ... (I mean how could I ? Realtek owns some of the code in there AFAIK ...)
Understood--thanks. I am not looking for legal advice, just reasonable confidence that I won't be responsible for a "diplomatic incident". I don't want to make enemies with a simple software release.
- Scott
On Tue, Sep 25, 2012 at 9:34 PM, Sylvain Munaut 246tnt@gmail.com wrote:
On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler scott@scottcutler.net wrote:
Do you have suggestions, then, as to the approach I should take? I plan
on
using a GPL-compatible license eventually, but the code isn't ready for
that
yet, and I'd like to head off any licensing issues in advance. What
about
interfacing only with ExtIO? So far, I have avoided that option because I've only had access to rtlsdr devices.
ExtIO would be acceptable if you don't distribute it bundled with it.
rtl_tcp is the completely isolated way.
Cheers,
SylvainPS: Of course this does not constitute legal advice and only represent my personal opinion and I don't represent all the copyright owners ... (I mean how could I ? Realtek owns some of the code in there AFAIK ...)
On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler scott@scottcutler.net wrote:
Do you have suggestions, then, as to the approach I should take? I plan on using a GPL-compatible license eventually, but the code isn't ready for that yet
Suggestion - don't spend time circumventing the GPL compatibility and release your code in open-source from the day one. Saved time could spend to get the software working better.
I have nothing against the GPL--but to me it represents an unknown that I would like to get out of the way as early as possible so that I no longer have to think about it. Although the software will never be commercial, I may have a future purpose for the software that involves connecting with closed-source code, and I simply don't know enough about the legal aspects there. I'd rather err on the side of safety when it comes to licensing. Part of the reason for developing my own software was to avoid just these kinds of difficulties.
Also, since ExtIO was on my list of things to support anyway, I may as well do it sooner rather than later.
At any rate, thanks for the advice.
-Scott
On Tue, Sep 25, 2012 at 9:40 PM, Alexander Chemeris < alexander.chemeris@gmail.com> wrote:
On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler scott@scottcutler.net wrote:
Do you have suggestions, then, as to the approach I should take? I plan
on
using a GPL-compatible license eventually, but the code isn't ready for
that
yet
Suggestion - don't spend time circumventing the GPL compatibility and release your code in open-source from the day one. Saved time could spend to get the software working better.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
Scott,
I’m in the situation where I can’t ship my code because I use commercial libraries which prevents me from supporting the RTL SDR as I can’t ship these libraries. The only way my software can support this device is for another developer to write a DLL which conforms to my own spec. (similar to ExtIO but different).
Simon G4ELI/HB9DRV
From: osmocom-sdr-bounces@lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Scott Cutler
Although the software will never be commercial, I may have a future purpose for the software that involves connecting with closed-source code, and I simply don't know enough about the legal aspects there.
Scott Cutler wrote:
I have nothing against the GPL--but to me it represents an unknown
Why don't you make it a known?
It's not really difficult to use dual licensing for your software should you want that at some point.
I may have a future purpose for the software that involves connecting with closed-source code, and I simply don't know enough about the legal aspects there.
So FIND OUT. You can ask license-related questions on the list too.
//Peter
Dual-licensing is an option I've considered. It may work, but I haven't thought through it fully yet.
The short answer here is that the legal stuff is *unbelievably boring* to me in comparison to coding, so if I can write 10 hours of code to save 2 hours of bashing my head against license documents, I will.
The rtl_tcp route sounds valid, and easy, and something I'd want anyway. I know there was a lot of drama surrounding SDR#, which is precisely why I came here to clear things up and not repeat the same mistakes.
So who wants to talk about actual SDR stuff instead? I see on the Osmocom pages that people already have POCSAG decoding, but FLEX isn't mentioned (I've only seen closed-source decoders). I have it working pretty well, both at 1600 and 6400 bps. Amazing how much medical stuff is being broadcast in the clear...
-Scott
On 9/26/2012 1:29 AM, Peter Stuge wrote:
Scott Cutler wrote:
I have nothing against the GPL--but to me it represents an unknown
Why don't you make it a known?
It's not really difficult to use dual licensing for your software should you want that at some point.
I may have a future purpose for the software that involves connecting with closed-source code, and I simply don't know enough about the legal aspects there.
So FIND OUT. You can ask license-related questions on the list too.
//Peter
Scott Cutler wrote:
The short answer here is that the legal stuff is *unbelievably boring* to me in comparison to coding, so if I can write 10 hours of code to save 2 hours of bashing my head against license documents, I will.
The rtl_tcp route sounds valid, and easy, and something I'd want anyway.
The interface clearly goes against the spirit of the license though. You shouldn't want to use it, if that makes sense.
//Peter
A separate executable, interfaced only over the network, implies pretty wide separation in my opinion. Web browsers that connect to GPL web servers aren't obligated to be open.
The reason I'd want it anyway is the network transparency--once I thought about it some, I really like the idea of setting up 3-4 dongles in my attic with different antennas. I have a server up there already, so I wouldn't need to run more wiring.
Look, as I said, I plan on open-sourcing this stuff anyway. I just need to reserve the possibility of distributing a closed-source personal branch that's still compatible with rtlsdr, and to possibly have a temporary period with a more restrictive license, like MS-RSL.
I haven't decided yet, at any rate. It may just remain a personal pet project if I don't have enough time to spend improving it first.
-Scott
On 9/26/2012 1:49 AM, Peter Stuge wrote:
Scott Cutler wrote:
The short answer here is that the legal stuff is *unbelievably boring* to me in comparison to coding, so if I can write 10 hours of code to save 2 hours of bashing my head against license documents, I will.
The rtl_tcp route sounds valid, and easy, and something I'd want anyway.
The interface clearly goes against the spirit of the license though. You shouldn't want to use it, if that makes sense.
//Peter
On Wed, Sep 26, 2012 at 5:06 AM, Scott Cutler scott@scottcutler.net wrote:
Look, as I said, I plan on open-sourcing this stuff anyway. I just need to reserve the possibility of distributing a closed-source personal branch that's still compatible with rtlsdr, and to possibly have a temporary period with a more restrictive license, like MS-RSL.
Note, that GPL has nothing to do with your personal use. GPL is triggered only when you convey your software to someone else, either by publishing on the Internet, or passing a flash drive from hands to hands. In both (and all other) cases GPL'ed software should be accompanied with the respective source code. If you do not give the software to anybody and use it by yourself - you don't have any obligations about the source code. If you give your software to someone on a flash drive, you don't need to put the source code on the Internet, it's fine to put them on the same flash drive. But the person who received the source code will be free to put the on the Internet.
This is in short. And surely, this is not a legal advise, etc, etc.
On Wed, Sep 26, 2012 at 8:18 AM, Scott Cutler scott@scottcutler.net wrote:
I have nothing against the GPL--but to me it represents an unknown that I would like to get out of the way as early as possible so that I no longer have to think about it. Although the software will never be commercial, I may have a future purpose for the software that involves connecting with closed-source code, and I simply don't know enough about the legal aspects there. I'd rather err on the side of safety when it comes to licensing. Part of the reason for developing my own software was to avoid just these kinds of difficulties.
If you keep the full copyright of the source code (that is, if you are the main developer and any other co-developers assign the copyright of their contributions to you), then you can relicense at will the new future versions of the source code.
However, the best approach would be to get into contact with the SLFC, http://www.softwarefreedom.org/ These licensing issues are their centre of interest, they like these things and they will help you decide which approach is best.
Some terms that help when communicating with the SFLC are 1. 'free software' is software that abides to the Free Software definition, http://en.wikipedia.org/wiki/The_Free_Software_Definition Practically, software licensed with the GPL is 'free software'. 2. 'open-source software' is software that make available the source code but do not fully abide with the Free Software Definition. Here you have the BSD-style licenses (you can take the source code, and you are permitted, if you want, to keep private your enhancements of your product) or the MPL license (the core is like free software, but it's OK to link with closed-source software). 3. 'copyright', anything you create has your copyright, which by default gives you exclusive rights to your creation. If you want others to use your creation, you add a license. Such as one of the above licenses. The free and open-source licences try to fix the situation that too few rights were given with proprietary software. 4. The aim of the free software movement is to create an ecosystem of free software, so that you are not stuck with some proprietary core component that hijacks the whole software stack. It's a novel aim.
Simos
-
Alexander Chemeris -
Peter Stuge -
Scott Cutler -
Simon G4ELI/HB9DRV -
Simos Xenitellis -
Sylvain Munaut