If you like SDR#, Don't Pirate SDR#


prog
 

Here we go again with a campaign of piracy for third party hardware. The last time this happened, we decided to restrict the SDR# innovations to our own hardware and a select list of partners. Now things just went savage, which will push the restrictions even further, which is unfortunate for our community.
Some end users even brag about their ability to use pirated software like if there was no tomorrow. I ask you to have some decency.
Finally, whoever writes the pirated dlls: Don't be someone else's fool. The IP law is not forgiving and a big dossier is being built. We know who you are.


John Dusek
 

Is there a backstory here I have totally missed?

 

Do we need to start a licensing scheme for only designated hardware with designated serial numbers?

 

Seems reasonable for Airspy products at any rate, you know what those are from the manufacturers, but how would it get limited for the other supported platforms?

 

From: airspy@groups.io [mailto:airspy@groups.io] On Behalf Of prog
Sent: Sunday, September 20, 2020 6:39 AM
To: airspy@groups.io
Subject: [Special] [airspy] If you like SDR#, Don't Pirate SDR#

 

Here we go again with a campaign of piracy for third party hardware. The last time this happened, we decided to restrict the SDR# innovations to our own hardware and a select list of partners. Now things just went savage, which will push the restrictions even further, which is unfortunate for our community.
Some end users even brag about their ability to use pirated software like if there was no tomorrow. I ask you to have some decency.
Finally, whoever writes the pirated dlls: Don't be someone else's fool. The IP law is not forgiving and a big dossier is being built. We know who you are.


jdow
 

Yes, there is. Long ago the source code for SDRSharp was officially available but with copying restrictions. I still have a source from that era. I'd used it for myself to perform some experiments. I never distributed it outwards. I also used it to develop a different rtlsdr.dll driver that used some of the changes I had incorporated into my rtlsdr.dll build.

Some people started redistributing the source code, with or without modifications, and incorporating SDRSharp code and techniques into their own projects which they distributed widely. Such is the Open Sores model; but, SDRSharp has NEVER been "Open Source", which I persist in calling "Open Sores". Kiddies seem to think it is entirely reasonable to take spare time while Daddy is paying all their bills to write code for free and distribute it. When it comes time to try to make money off their project they discover they can do one of two things, starve on the streets or spend their lives answering endless support calls for money. The only escape from this is to become something BIG like Linux or Mozilla that has corporate sponsors and donors. That is an unlikely event. So, of course, Youssef is still pretty torqued (embittered may be a better word) by this state of affairs. (It is probably why Simon is keeping SDR-Radio (Vn) close to his vest and under his control, too. Simon is retired, the other state of affairs that allows developing software "mostly" for free. Youssef is not an old critter like me or like Simon. He cannot afford to give away his work effort. If somebody with a lot of money wants Youssef to give it away, passing large, really large, chunks of that somebody's excess money (instead of spending it on crack or something.)

{^_^}

On 20200920 06:06:25, John Dusek wrote:

Is there a backstory here I have totally missed?

 

Do we need to start a licensing scheme for only designated hardware with designated serial numbers?

 

Seems reasonable for Airspy products at any rate, you know what those are from the manufacturers, but how would it get limited for the other supported platforms?

 

From: airspy@groups.io [mailto:airspy@groups.io] On Behalf Of prog
Sent: Sunday, September 20, 2020 6:39 AM
To: airspy@groups.io
Subject: [Special] [airspy] If you like SDR#, Don't Pirate SDR#

 

Here we go again with a campaign of piracy for third party hardware. The last time this happened, we decided to restrict the SDR# innovations to our own hardware and a select list of partners. Now things just went savage, which will push the restrictions even further, which is unfortunate for our community.
Some end users even brag about their ability to use pirated software like if there was no tomorrow. I ask you to have some decency.
Finally, whoever writes the pirated dlls: Don't be someone else's fool. The IP law is not forgiving and a big dossier is being built. We know who you are.



antigraviton@...
 

Forgive me if I've missed something but the use of the software is free, right? So why keep it closed source?

Again, forgive if I'm stepping on already sore toes, I'm not out to hurt anyone, but is the problem not with the business model rather than with the pirating of old code (I'm referring to the 'Long ago the source code ... was ... available'?

From my perspective, monetisation of software development has long been surpassed by other, more lucrative models, payed support being just one of many. I haven't seen the source code and am not really the person who can appreciate code quality, but I can get an impression from a user perspective: it looks and feel like good software, attesting to the qualities of everyone involved. And there is a huge market for 'good' software engineers, right?

Having said that, the RF and RF-hobby market is a niche market, making successful business models difficult...

From experience, reducing or hampering functionality has never been a recipe for greatness or success.


prog
 

On Mon, Sep 21, 2020 at 12:00 PM, <antigraviton@...> wrote:
Forgive me if I've missed something but the use of the software is free, right? So why keep it closed source?
Sounds like a brilliant idea.


Martin - G8JNJ
 

On Mon, Sep 21, 2020 at 10:00 AM, <antigraviton@...> wrote:
payed support being just one of many.
Yep, it's providing after sales support that eats up all the profit, even if the software is 'free'.

Folks like M$ seem to be realising this too, and I think yearly 'subscription' models will become the norm, where basically you are just renting software rather than actually buying (owning) it.

Regards,

Martin



John Dusek
 

I for one would be open to a “voluntary pay” model (like supporting public radio in the US) where you can set up a contribution/support model for those willing to pay towards the value they feel they receive.

 

That may already exist here and I am just ignorant of the option.

 

Otherwise you can use it without paying if you want to get a free ride.

 

In either case Prog/Youssef could maintain control of the source code – it’s his baby.  But he would get some ongoing monetary assistance for his passion/investment.

 

I know there is SOME (likely small) monetary reward on the Airspy hardware side of things, but hardware can get cloned/stolen and the software is the ongoing living feature that allows him to keep control.

 

From: airspy@groups.io [mailto:airspy@groups.io] On Behalf Of Martin - G8JNJ via groups.io
Sent: Monday, September 21, 2020 5:30 AM
To: airspy@groups.io
Subject: Re: [airspy] If you like SDR#, Don't Pirate SDR#

 

On Mon, Sep 21, 2020 at 10:00 AM, <antigraviton@...> wrote:

payed support being just one of many.

Yep, it's providing after sales support that eats up all the profit, even if the software is 'free'.

Folks like M$ seem to be realising this too, and I think yearly 'subscription' models will become the norm, where basically you are just renting software rather than actually buying (owning) it.

Regards,

Martin


prog
 
Edited

Just don't be fooled by the Marxist view of software development. It's Airspy that pays you SDR# and all the fancy algorithms that have spread to other SDR stacks and democratized the use of low cost hardware at a reasonable performance. Free riders are going to free-ride whenever possible, be it legally or illegally, and we have just witnessed an instance of it.
And no, thanks for the business model advice. Our organization is based on actual field experience (plus a decade of actual financial engineering), not a pub discussion. If you are new to hobby SDR, there's a ton of reading waiting for you in this same mailing list to understand how it all started and how we got where we are now. This will also avoid you some embarrassing comments from the community. (Just an advice!)

To summarize how it works:
- We do the R&D hard work (RF, Hardware, DSP, Software)
- You get a fancy incredibly simple SDR stack based on mass produced chips
- Our DSP/Control Software compensates for the intrinsic weaknesses of the mass produced chips
- Parts of that DSP and software is open source (the drivers + important DSP post-processing)
- The other part is maintained by a select few who know what they are doing. We tried to involve more people into the party, but this ended up in a big mess from VB button colorizers whose entry ticket to hardcore DSP has become cheap.

Now plug the free-riders in the last two steps in any imaginable way, and you get an idea how things work in the real world.
I hope this post will answer most of the questions.

As always, expect more disrupting innovations that will bring an unprecedented performance at hobby budget.

Stay tuned!


John Dusek
 

Thank you for the fast for the feedback.

 

I just want to register my appreciation for the HW (I have Airspy R2, HF+ Dual Port, and HF+ Discovery), so I definitely believe in the pay for what you use model.    

 

I am a big fan of the SDR# software and continuous improvement/pushing the performance envelope that Airspy’s HW/SW combination are driving.

 

 

From: airspy@groups.io [mailto:airspy@groups.io] On Behalf Of prog
Sent: Monday, September 21, 2020 6:16 AM
To: airspy@groups.io
Subject: Re: [airspy] If you like SDR#, Don't Pirate SDR#

 

Just don't be fooled by the Marxist view of software development. It's Airspy that pays you SDR# and all the fancy algorithms that have spread to other SDR stacks and democratized the use of low cost hardware at a reasonable performance. Free riders are going to free-ride whenever possible, be it legally or illegally, and we have just witnessed an instance of it.
And no, thanks for the business model advice. Our organization is based on actual field experience (plus a decade of actual finacial engineeing), not a pub discussion. If you are new to hobby SDR, there's a ton of reading waiting for you in this same mailing list to understand how it all started and how we got where we are now. This will also avoid you some embarrassing comments from the community. (Just an advice!)

To summarize how it works:
- We do the R&D hard work (RF, Hardware, DSP, Software)
- You get a fancy incredibly simple SDR stack based on mass produced chips
- Our DSP/Control Software compensates for the intrinsic weaknesses of the mass produced chips
- Parts of that DSP and software is open source (the drivers + important DSP post-processing)
- The other part is maintained by a select few who know what they are doing. We tried to involve more people into the party, but this ended up in a big mess from VB button colorizers whose entry ticket to hardcore DSP has become cheap.

Now plug the free-riders in the last two steps in any imaginable way, and you get an idea how things work in the real world.
I hope this post will answer most of the the questions.

As always, expect more disrupting innovations that will bring an unprecedented performance at hobby budget.

Stay tuned!


Brian Gregory <bdgregory@...>
 

For one thing if it was open source then other SDR manufacturers would copy it and make it work with their hardware and then it could help them steal Airspy's share of the market away.

Brian Gregory.
bdgregory@...
www.Brian-Gregory.me.uk
(Home)
On 21/09/2020 11:00, antigraviton@... wrote:

Forgive me if I've missed something but the use of the software is free, right? So why keep it closed source?

Again, forgive if I'm stepping on already sore toes, I'm not out to hurt anyone, but is the problem not with the business model rather than with the pirating of old code (I'm referring to the 'Long ago the source code ... was ... available'?

From my perspective, monetisation of software development has long been surpassed by other, more lucrative models, payed support being just one of many. I haven't seen the source code and am not really the person who can appreciate code quality, but I can get an impression from a user perspective: it looks and feel like good software, attesting to the qualities of everyone involved. And there is a huge market for 'good' software engineers, right?

Having said that, the RF and RF-hobby market is a niche market, making successful business models difficult...

From experience, reducing or hampering functionality has never been a recipe for greatness or success.


Milen Rangelov
 

I personally admire the great hardware Airspy allowed all of us to own for cheap and I have both an Airspy R2 and a HF+. That said, I don't use SDRsharp at all. Not just because my primary OS is Linux, also because I see nothing wrong in "marxist" "open-sore" software and I really do prefer that model. I fully respect the SDRSharp license since that's the authors' choice to start with. Not how I would use the hardware though. So rather than disrespecting the license, please do get involved in open-source projects development. Whether that would be gqrx, another general-use SDR project or you start your very own one.

I also tend to disagree with Youssef on political stuff (thing is I unlike him I did live under a "marxist" regime to start with). Disagreeing with that doesn't mean I have the right to shit on his efforts. Please DO NOT DISRESPECT the license. Do get involved in opensource projects. You know, Airspy SDRs don't only work with SDR#, right?

Regards,
Milen Rangelov


On Mon, Sep 21, 2020 at 11:41 PM Brian Gregory <bdgregory@...> wrote:

For one thing if it was open source then other SDR manufacturers would copy it and make it work with their hardware and then it could help them steal Airspy's share of the market away.

Brian Gregory.
bdgregory@...
www.Brian-Gregory.me.uk
(Home)
On 21/09/2020 11:00, antigraviton@... wrote:
Forgive me if I've missed something but the use of the software is free, right? So why keep it closed source?

Again, forgive if I'm stepping on already sore toes, I'm not out to hurt anyone, but is the problem not with the business model rather than with the pirating of old code (I'm referring to the 'Long ago the source code ... was ... available'?

From my perspective, monetisation of software development has long been surpassed by other, more lucrative models, payed support being just one of many. I haven't seen the source code and am not really the person who can appreciate code quality, but I can get an impression from a user perspective: it looks and feel like good software, attesting to the qualities of everyone involved. And there is a huge market for 'good' software engineers, right?

Having said that, the RF and RF-hobby market is a niche market, making successful business models difficult...

From experience, reducing or hampering functionality has never been a recipe for greatness or success.


Edward MacDonald
 

You buy a Tesla, it come with software to run it. Do you think they should open source that also ?? "Free" software does not mean free from value.


On Mon., Sep. 21, 2020, 4:17 a.m. prog, <info@...> wrote:
On Mon, Sep 21, 2020 at 12:00 PM, <antigraviton@...> wrote:
Forgive me if I've missed something but the use of the software is free, right? So why keep it closed source?
Sounds like a brilliant idea.


Phil Karn
 

On 9/21/20 14:00, Edward MacDonald wrote:
You buy a Tesla, it come with software to run it. Do you think they
should open source that also ?? "Free" software does not mean free
from value.
We own two Teslas, and yes, I do believe the software should be open
sourced. There are too many safety-related functions in there for it to
go unreviewed by the widest possible set of eyeballs. There's too little
transparency about exactly what information is being reported to Tesla.
There are simple bugs that have gone unfixed for years. There is an
annoying trend toward nanny features in the software like suddenly
reducing the speed of the car when it thinks the speed limit has dropped
-- often incorrectly. And while Tesla seems fairly solid right now,
there's always the possibility that it could go out of business and
leave us with black (or white) boxes that can't be maintained at all.

Was this the answer you were looking for?

Phil


Marcus D. Leech
 

On 09/21/2020 06:13 PM, Phil Karn wrote:
On 9/21/20 14:00, Edward MacDonald wrote:
You buy a Tesla, it come with software to run it. Do you think they
should open source that also ?? "Free" software does not mean free
from value.
We own two Teslas, and yes, I do believe the software should be open
sourced. There are too many safety-related functions in there for it to
go unreviewed by the widest possible set of eyeballs. There's too little
transparency about exactly what information is being reported to Tesla.
There are simple bugs that have gone unfixed for years. There is an
annoying trend toward nanny features in the software like suddenly
reducing the speed of the car when it thinks the speed limit has dropped
-- often incorrectly. And while Tesla seems fairly solid right now,
there's always the possibility that it could go out of business and
leave us with black (or white) boxes that can't be maintained at all.

Was this the answer you were looking for?

Phil

I don't really care that much about SDR# being closed source. The driver code is open source, which means that the hardware is
usable by a lot of other software, including software that isn't all about "casual air-wave surfing". So, meh.

In the USRP space there were some folks who resented the fact that nearly everything was open-source, except for all the CAD data that would
be required to just have the things contract manufactured. There were seriously folks who felt that you're either "Open Source All The Way",
or entirely closed source, and that having the CAD data not be available was somehow "unfair". Which, to me, seems pants-on-head stupid.
Like you owe the world a vow of poverty if you enter the open-source-friendly hardware world.


Phil Karn
 

On 9/21/20 15:26, Marcus D. Leech wrote:
I don't really care that much about SDR# being closed source.  The
driver code is open source, which means that the hardware is
  usable by a lot of other software, including software that isn't all
about "casual air-wave surfing".  So, meh.
I concur with this. It's the author's choice whether to open source his
code or not, so references to "software Marxism" are out of line. That
said, experience has shown that the open source model works and works
well. If he doesn't choose it, that's ultimately his loss.

I don't use SDR# for the simple reason that I don't run Windows. And
yeah, like you I'm doing a lot more than casual air-wave surfing, hence
I write my own code (which I choose to open source).


In the USRP space there were some folks who resented the fact that
nearly everything was open-source, except for all the CAD data that would
  be required to just have the things contract manufactured.  There
were seriously folks who felt that you're either "Open Source All The
Way",
  or entirely closed source, and that having the CAD data not be
available was somehow "unfair".  Which, to me, seems pants-on-head
stupid.
  Like you owe the world a vow of poverty if you enter the
open-source-friendly hardware world.
Agreed, if you're just buying one copy of a piece of existing hardware.
(Any bogus patents would have been a different story). But if I were
asked to donate my own money to a hardware development project, I
wouldn't do it unless the developers agreed to open everything up,
including the CAD files. That'd be my money and my choice.

Phil


Phil Karn
 

On 9/21/20 15:26, Marcus D. Leech wrote:

In the USRP space there were some folks who resented the fact that
nearly everything was open-source, except for all the CAD data that would
  be required to just have the things contract manufactured.
There is actually a very pragmatic reason for such a position: ensuring
the continued availability of the hardware if the manufacturer goes out
of business or discontinues the product so you don't lose your own
personal investment in developing for it.

At the same time, multiple sourcing can sometimes be an acceptable
substitute, especially if the item is already a de-facto standard that
takes substantial resources to make (canonical example: x86-64 CPU chips
made by both Intel and AMD and occasionally others.)

I really do not like investing a lot of my own time writing code for
someone's proprietary product, putting myself at the mercy of its
supplier. While I do write C code on an Apple MacBook, I don't write for
OSX itself but for the (almost) generic BSD UNIX system below it. It's
close enough to Linux (my primary target) that it's usually not much
extra work to ensure the code also runs on OSX's BSD subsystem.

I'm willing to learn enough about the Airspy to write software that will
use it because my investment of time is fairly small. Also, I don't want
to disparage Airspy's products because they're actually fairly good, but
they are already generic enough that my investment can be shared among
several similar devices. There are only so many ways to build an SDR
front end with low IF/direct conversion.

Phil


Edward MacDonald
 

With all due respect Phil...

"There are only so many ways to build an SDR
front end with low IF/direct conversion."

Really? Then that must be why people are constantly asking Prog to "gimme dem codes" all the time eh?

On Mon., Sep. 21, 2020, 5:31 p.m. Phil Karn, <karn@...> wrote:
On 9/21/20 15:26, Marcus D. Leech wrote:
>
> In the USRP space there were some folks who resented the fact that
> nearly everything was open-source, except for all the CAD data that would
>   be required to just have the things contract manufactured.

There is actually a very pragmatic reason for such a position: ensuring
the continued availability of the hardware if the manufacturer goes out
of business or discontinues the product so you don't lose your own
personal investment in developing for it.

At the same time, multiple sourcing can sometimes be an acceptable
substitute, especially if the item is already a de-facto standard that
takes substantial resources to make (canonical example: x86-64 CPU chips
made by both Intel and AMD and occasionally others.)

I really do not like investing a lot of my own time writing code for
someone's proprietary product, putting myself at the mercy of its
supplier. While I do write C code on an Apple MacBook, I don't write for
OSX itself but for the (almost) generic BSD UNIX system below it. It's
close enough to Linux (my primary target) that it's usually not much
extra work to ensure the code also runs on OSX's BSD subsystem.

I'm willing to learn enough about the Airspy to write software that will
use it because my investment of time is fairly small. Also, I don't want
to disparage Airspy's products because they're actually fairly good, but
they are already generic enough that my investment can be shared among
several similar devices. There are only so many ways to build an SDR
front end with low IF/direct conversion.

Phil











jdow
 

So how does Tesla make money to pay for the research embodied into that software? It must it all be done for free?

{o.o}

On 20200921 15:13:27, Phil Karn wrote:
On 9/21/20 14:00, Edward MacDonald wrote:
You buy a Tesla, it come with software to run it. Do you think they
should open source that also ?? "Free" software does not mean free
from value.
We own two Teslas, and yes, I do believe the software should be open
sourced. There are too many safety-related functions in there for it to
go unreviewed by the widest possible set of eyeballs. There's too little
transparency about exactly what information is being reported to Tesla.
There are simple bugs that have gone unfixed for years. There is an
annoying trend toward nanny features in the software like suddenly
reducing the speed of the car when it thinks the speed limit has dropped
-- often incorrectly. And while Tesla seems fairly solid right now,
there's always the possibility that it could go out of business and
leave us with black (or white) boxes that can't be maintained at all.

Was this the answer you were looking for?

Phil









Jordan Hayes
 

how does Tesla make money
(I guess you're not paying close attention ...)


Edward MacDonald
 

I believe Musk said the price of the car accounts for R & D and software base development. My point was this: if you purchase a piece of hardware and recieve a copy of the software to run it, that does not automatically entitle you to the source code of that software unless specifically stated in the license agreement. Seems a lot of people on here thinking they have entitlement to the source because they installed the app or purchased an Airspy device



On Mon., Sep. 21, 2020, 6:15 p.m. jdow, <jdow@...> wrote:
So how does Tesla make money to pay for the research embodied into that software? It must it all be done for free?

{o.o}

On 20200921 15:13:27, Phil Karn wrote:
On 9/21/20 14:00, Edward MacDonald wrote:
You buy a Tesla, it come with software to run it. Do you think they
should open source that also ?? "Free" software does not mean free
from value.
We own two Teslas, and yes, I do believe the software should be open
sourced. There are too many safety-related functions in there for it to
go unreviewed by the widest possible set of eyeballs. There's too little
transparency about exactly what information is being reported to Tesla.
There are simple bugs that have gone unfixed for years. There is an
annoying trend toward nanny features in the software like suddenly
reducing the speed of the car when it thinks the speed limit has dropped
-- often incorrectly. And while Tesla seems fairly solid right now,
there's always the possibility that it could go out of business and
leave us with black (or white) boxes that can't be maintained at all.

Was this the answer you were looking for?

Phil