SDR# JUST STOP!

[silberj]

I uninstalled it a while back. DSD+ FL, and HDSDR FTW. SDRTrunk if your sexy.

 

[air-scan]

I uninstalled it a while back. DSD+ FL, and HDSDR FTW. SDRTrunk if your sexy.

All 3 on mine but I DSD+ FL FMP24 having fits with xHCL 3.1 USB controller. That's already been discussed in my other thread.

I think SDR# is good software and we should be giving prog leniency. I still am using SDR# still. Still a big number of people will enjoy SDR#. Let's be fair. He does a good job. I think what he said was a warning in case it does happen again. I can't prove anything is happening or not in the terms of piracy of SDR# being just a end user. It's my go-to software for FM Broadcast band with good stereo and RDS. Sounds sweeter through the B&O audio equalizer that came with my laptop.

 

[EricCottrell]

Hello,

I looked at the zip file in question and it is interesting.

One of the changes done around the time of the ExtIO elimination was to use an internal whitelist of frontend plugins. The FrontEnds.xml file is not used anymore. So to use another frontend plugin you need to make it look like a white-listed plugin. In this case it is the UHD/USRP, an approved frontend that does not have a supplied dll.

The developer of the ExtIO frontend did use files from the ExtIO portion of a somewhat open-source version of SDRSharp. Most of the files use the MIT License. The ExtIO files are in the Radio portion under the MS-RSL license. This license appears to be similar to the license file in the radio subdirectory. This is the same license that is included in distributions of SDRSharp. By my reading, the license is really meant for Microsoft C# libraries (assemblies). It mentions being able to reference the product, but not to use it to develop the same or similar functionality for a product on a non-Windows operating system. It does not fit SDRsharp as an end-user license as well.

The Ext-IO plugin is not a competing product. The plugin developer is using code from an older version to add functionality back into the same program. It would be cleaner if the developer avoided the murky licensing and developed ExtIO code separate from the original ExtIO code. In my mind it is not a clear cut case of using the plugin or not.

The SDRsharp developers did not do a good job taking SDRSharp to fully closed source. They seem to have an unreasonable expectation of what they did gives them total control of all the source from the beginning. This is not how open source works. It seems they wanted the benefits of open source while still fully controlling the source.

73 Eric

 

[eorange]

Your last sentence is exactly correct. And this is not surprising in the least.

 

[kb9mwr]

I love tasty karma. Just look at how much open source software thrives here (and everywhere else in the world). prog gets what he deserves.

I couldn't have said it better. Now if we just had smarter end users/consumers..

 

[ArloG]

Well they sure got their panties in a bunch when SDRSharper came out. And peed a lot of people off who suddenly lost EXTIO functionality after...what? ver. 1361??
I'd suspect a little bit of money trading hands from the RTL based hardware vendors.
And what of the tons of plugins for Sharp from people who write code for the fun of it?
I'm a big fan of HDSDR for my IC-R8600 and RSP2. Probably the easiest, most direct, and non-cluttered SDR front end application out there.
Another big surprise (for me anyhow) was that DSD+ Fastlane also would like for you to have a couple of RTL dongles at the very least.
I'm glad that there is support for the SDRPlay for frequency hopping. That's not something that they really plant out in the open and that radio support for non-RTL, SDRPlay receivers is non-existent.

 

[slicerwizard]

Another big surprise (for me anyhow) was that DSD+ Fastlane also would like for you to have a couple of RTL dongles at the very least.

A couple of dongles for what?

I'm glad that there is support for the SDRPlay for frequency hopping. That's not something that they really plant out in the open and that radio support for non-RTL, SDRPlay receivers is non-existent.

Don't the traffic steering files that DSD+ creates let anyone build support for whatever receiver they want?

 

[ArloG]

A couple of dongles for what?
An answer you would know all too well. Actually there is a new post here asking about using 2 dongles. Let's jump over there.

Don't the traffic steering files that DSD+ creates let anyone build support for whatever receiver they want?

Receiver not scanner. If monitoring a control channel how would a person get it to jump over to a voice channel and then the next?
Willing to learn. Especially since a few strong p25 xmitters popped up here recently. Possibly start a new thread on that one? Eh?

 

[slicerwizard]

No, I do not know why DSD+ Fastlane also would like for you to have a couple of RTL dongles at the very least. Any time I'm mobile, I typically use only one FlightAware dongle, regardless of what I'm monitoring, so this is where you stop talking in riddles.

 

[KA1RBI]

Wow, reading this thread reminds me why I left the world of windows decades ago, never really looked back. An interesting contrast between the two worlds is manifest in the SDR space; specifically, hardware drivers. Most linux SDR apps utilize the gr-osmosdr hardware drivers, which means the apps themselves need not be modified each time a new piece of SDR hardware is out. I've lost count of how many times I've seen windows users on here begging for their favorite app X to support SDR hardware Y. The trouble with this approach is that each different app has to be modified/extended to support each different type of SDR. Wouldn't it be nice if there were a way out of that treadmill?

Also, separately, I want to take this opportunity to encourage as many users as possible to "pirate" OP25 and disseminate it as widely as possible.

Not understanding the legalities of all of this stuff, I went ahead and joyfully used the 8600 with it; it is a great combination but I am going to sadly stop doing so and find another solution.

Sad! If ANY user of OP25 is joyfully using it I want to encourage that to continue!!

Don't want people doing unintended stuff with your software? Do a better job at locking it down.

This kind of mentality is ... strange. As a software author I always find it most interesting and serendipitous as I rediscover that users are in general smarter than I am and have found ways to use the software in new "unintended" ways.

In particular I especially approve of "unapproved" hardware interfaces, most especially homebrew.

Earlier on in the life of sdsharp it was open source. Prog decided to remove that after someone effectively brought out a closed source version of the open source code and with a new name. That is clearly wrong on many levels.

Wow, that one sounds familiar. Did you think it was wrong on any levels when someone brought out a closed source version of the open source code, DSD?

Max

 

[air-scan]

Wow, reading this thread reminds me why I left the world of windows decades ago, never really looked back. An interesting contrast between the two worlds is manifest in the SDR space; specifically, hardware drivers. Most linux SDR apps utilize the gr-osmosdr hardware drivers, which means the apps themselves need not be modified each time a new piece of SDR hardware is out. I've lost count of how many times I've seen windows users on here begging for their favorite app X to support SDR hardware Y. The trouble with this approach is that each different app has to be modified/extended to support each different type of SDR. Wouldn't it be nice if there were a way out of that treadmill?

Also, separately, I want to take this opportunity to encourage as many users as possible to "pirate" OP25 and disseminate it as widely as possible.



Sad! If ANY user of OP25 is joyfully using it I want to encourage that to continue!!



This kind of mentality is ... strange. As a software author I always find it most interesting and serendipitous as I rediscover that users are in general smarter than I am and have found ways to use the software in new "unintended" ways.

In particular I especially approve of "unapproved" hardware interfaces, most especially homebrew.



Wow, that one sounds familiar. Did you think it was wrong on any levels when someone brought out a closed source version of the open source code, DSD?

Max

We're not talking about OP25. SDR# is the subject.

 

[kb9mwr]

We're not talking about OP25. SDR# is the subject.

Its much all the same story if you ask me. The RTL-SDR driver and whole concept of software defined radio is meant to be open (as in source code available)... the story time and time again is; some schmoe, comes along and creates some closed source pretty windows thing that attracts attention of newbies, and any improvements from what open source thing they built off of never make it back upstream. The newbies are still dependent on this one guy. No one learns anything, and the world becomes dumber.

The title of this thread says it all. "Just stop" supporting this stupidity.

 

[air-scan]

Its much all the same story if you ask me. The RTL-SDR driver and whole concept of software defined radio is meant to be open (as in source code available)... the story time and time again is; some schmoe, comes along and creates some closed source pretty windows thing that attracts attention of newbies, and any improvements from what open source thing they built off of never make it back upstream. The newbies are still dependent on this one guy. No one learns anything, and the world becomes dumber.

The title of this thread says it all. "Just stop" supporting this stupidity.

Osmocom never closed source OP25. Forks of OP25 exist under GNU. SDR# developer is the one doing the complaining and besides I was being sarcastic because I remember that developer had tantrums before about it and I have agreed with some replies on this thread. I would leave OP25 out of it!

Do you think Unitrunker and SDRTrunk are guilty to? How about SDRPlay and ETTUS research? Are they guilty? I think it would be absurd to even mention.

 

[belvdr]

whole concept of software defined radio is meant to be open (as in source code available)...

Software defined “anything” does not automatically mean open source.

 

[kb9mwr]

Software defined “anything” does not automatically mean open source.

No, but without that you aren't going to be able to build upon it.

 

[belvdr]

No, but without that you aren't going to be able to build upon it.

That’s incorrect. Many closed source systems have APIs to extend it.

 

[kb9mwr]

That’s incorrect. Many closed source systems have APIs to extend it.

Yeah ok, got me on a technicality. I'm not going to sit here and argue.

For me, since I am a ham who likes to tinker, SDR is about learning and working with others to keep it moving forward. A closed source Windows SDR program is about as exciting to me as a Baofeng.

Just like in the days past (when people weren't just operators) they'd look at schematics to learn how their radios work. They make modifications to make them receive better or what have you. They'd share that info with other mostly by print media.

They way I see it, most of the underpinnings of SDR, the RTL-SDR driver and GNU radio are open source. Had they not been, then we'd likely not be as far as we are today.

 

[belvdr]

Yeah ok, got me on a technicality. I'm not going to sit here and argue.

For me, since I am a ham who likes to tinker, SDR is about learning and working with others to keep it moving forward. A closed source Windows SDR program is about as exciting to me as a Baofeng.

Just like in the days past (when people weren't just operators) they'd look at schematics to learn how their radios work. They make modifications to make them receive better or what have you. They'd share that info with other mostly by print media.

They way I see it, most of the underpinnings of SDR, the RTL-SDR driver and GNU radio are open source. Had they not been, then we'd likely not be as far as we are today.

I'm not arguing, just discussing. Differing opinions make for interesting discussion.

I doubt many people even look at, or could possibly understand, any source code (me included). I think open source is a great idea, but for me as a user, it makes no difference one way or the other.

 

[thewraith2008]

Isn't the problem that SDR# once allowed anybody to create frontends (via the free and available API) for different hardware only for 'prog' to then turn around and start calling the frontend developers cheats/liars/pirates because he decided that he did not like other hardware to be use with SDR# anymore.

He says:

The new way of having some hardware support done is to have it developed by us. It's not hard to understand that piracy may have some collateral consequences.
On the bright side, the legit hardware will benefit from unforeseen features that were sitting in the drawer.

And on the dark side this, "some hardware support" is at the mercy of when he feels/wants to spend time on it and only to adding 'features' that he wants possibly crippling hardware as not to shine to bright.

It's a crying shame that SDR# is further removing features that made it good to develop for in the first place.

 

[kb9mwr]

I'm not arguing, just discussing. Differing opinions make for interesting discussion.

I doubt many people even look at, or could possibly understand, any source code (me included). I think open source is a great idea, but for me as a user, it makes no difference one way or the other.

I agree for most end users they don't care. Just like how most people don't care about trying to buy American vs Chinese.

The problem always lies in the very dedicated open source authors like osmocom, the original DSD author, Max, and an endless list of others. I totally understand how disgusted they get when someone takes what they have openly shared for the greater good and then creates in violation of the GPL a closed source fork... and what's even more despicable is when they do that and monetize off it.

Conservancy Announces New Strategy for GPL Enforcement and Related Work, Receives Grant from ARDC

Software Freedom Conservancy, the only organization actively engaged in General Public License (GPL) enforcement and compliance work for Linux, announces today a new strategy toward improving compliance and the freedom of users of devices that contain Linux-based systems. The new work has...

sfconservancy.org