Hi Xaver,
[posting this on the mailing list, as it may be of interest to others]
On Fri, Sep 11, 2020 at 04:55:35PM +0200, Xaver Zu wrote:
This is a dynamic linking.
this is true, but the nature of the linking does not matter in terms of what creates the derivative work.
Is this a problem even if I do not distribute the resulting binary?
The AGPL (contrary to the GPL) conditions start when users remotely interact with your software (See Section 13 of AGPLv3). This means even operating a network with remote users already means you need to provide the complete and corresponding source code to the entire work under AGPLv3, which is impossible if you have a proprietary dependency.
So if you build the software, and you make sure that nobody but yourself every uses the resulting GSM network, you are fine. But as soon as any third party uses it, you would be putting yourself in the impossible position to providing the source code to a proprietary library.
I can simply add a warning to the file that the compiled program cannot be distributed.
One might consider this a "further restriction" which by itself is a violation of AGPLv3:
All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. [...] You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.
But even beyond that: How many users do you think willread that warning in the source code vs. how many will simply run it (and possibly allow others to register). Even if you added a message to start-up, and to the user manual, I still would think many people don't look at that.
I don't think we should distribute something that "tricks" people into committing license violations or putting them in an impossible position, legally speaking.
Is it a violation that someone assembles and uses it on their own machine?
It is not a violation as long as they are they only person using the resulting GSM network (or using its VTY or its TRXC/TRXD interface).
I would compare distributing source code like that to shipping a product that is almost impossible to use safely, but very easy to use in a [legally] unsafe way.
Is it a violation to even have sources and build instructions for it?
Maybe not, but see above, I don't want to make it too easy for people to shoot themselves into their foot.
Can we agree to leave it as a starting point until someone will have the time to do it using IPC?
I'm very sorry (really), but we will not merge this code to the mainline osmo-trx code base on osmocom.org.
Kind regards, Harald
Let me see if I understand the PCIeSDR proprietary libsdr.so situation correctly. There is a hardware vendor (Amarisoft) who produces a piece of hardware, but refuses to provide FLOSS support for it, and instead provides an essential layer (required for the device to work) only in the form of a proprietary binary library with no source - is this understanding correct?
Does this vendor have competitors? Are there other companies who make SDR devices in PCIe form factor, but who provide all necessary support pieces in full source form under an Osmocom-compatible license? Maybe LimeSDR PCIe? If such alternative non-proprietary vendors exist, why not vote with your dollars against proprietary blobs by giving your business to better vendors rather than Amarisoft?
OTOH if you personally (Xaver) already invested into Amarisoft hardware and don't want your work to go to waste because of license worship, I encourage you to maintain your own fork of OsmoTRX outside of osmocom.org and thus out of reach of their license police. I will never use it myself or even look at it because this kind of SDR is not my area of interest, but I am encouraging you as a matter of general principle, just like my predecessor Che Guevara would have.
M~
I use it in a laboratory with 1-2 clients. It's about backing up that job when I've already invested time. It seems that the master branch is impossible for this. I have it in a private fork.
Is it possible in its current form to have it in any branch? Can it at least stay in the gerrit?
Basically the main problem is that I link with the libsdr.so library but I can't publish the source codes. I don't have them. Could I solve this with an open source (GPL) reimplementation of that library?
pá 11. 9. 2020 v 19:07 odesílatel Mychaela Falconia < mychaela.falconia@gmail.com> napsal:
Let me see if I understand the PCIeSDR proprietary libsdr.so situation correctly. There is a hardware vendor (Amarisoft) who produces a piece of hardware, but refuses to provide FLOSS support for it, and instead provides an essential layer (required for the device to work) only in the form of a proprietary binary library with no source - is this understanding correct?
Does this vendor have competitors? Are there other companies who make SDR devices in PCIe form factor, but who provide all necessary support pieces in full source form under an Osmocom-compatible license? Maybe LimeSDR PCIe? If such alternative non-proprietary vendors exist, why not vote with your dollars against proprietary blobs by giving your business to better vendors rather than Amarisoft?
OTOH if you personally (Xaver) already invested into Amarisoft hardware and don't want your work to go to waste because of license worship, I encourage you to maintain your own fork of OsmoTRX outside of osmocom.org and thus out of reach of their license police. I will never use it myself or even look at it because this kind of SDR is not my area of interest, but I am encouraging you as a matter of general principle, just like my predecessor Che Guevara would have.
M~
On Fri, Sep 11, 2020 at 08:09:16PM +0200, Xaver Zu wrote:
Basically the main problem is that I link with the libsdr.so library but I can't publish the source codes. I don't have them. Could I solve this with an open source (GPL) reimplementation of that library?
Yes! Please do let us know where you publish this if you do write such a reimplementation.
Denver https://jmp.chat/
Hi Xaver,
It's about backing up that job when I've already invested time.
Yes, I totally empathize with you on this one!
Is it possible in its current form to have it in any branch? Can it at least stay in the gerrit?
Given their stance on license worship, I highly doubt that the owners of osmocom.org domain and infrastructure would allow license-violating stuff to be hosted anywhere under their domain. But I can give you hosting on freecalypso.org if you like - I am a proud pirate. :-)
M~
pá 11. 9. 2020 v 20:36 odesílatel Mychaela Falconia < mychaela.falconia@gmail.com> napsal:
Hi Xaver,
It's about backing up that job when I've already invested time.
Yes, I totally empathize with you on this one!
Is it possible in its current form to have it in any branch? Can it at least stay in the gerrit?
Given their stance on license worship, I highly doubt that the owners of osmocom.org domain and infrastructure would allow license-violating stuff to be hosted anywhere under their domain. But I can give you hosting on freecalypso.org if you like - I am a proud pirate. :-)
M~
Please refrain from any personal attacks, we are guests here. People in this community have a right to their position. The GPL license seems to be on their side. I don't feel any frustration.
I want to solve factual problems objectively. Formal problems formally.
Denver please, if you have any doubts we could discuss about it.
Xaver
pá 11. 9. 2020 v 20:49 odesílatel Xaver Zu xaver1zu@gmail.com napsal:
pá 11. 9. 2020 v 20:36 odesílatel Mychaela Falconia < mychaela.falconia@gmail.com> napsal:
Hi Xaver,
It's about backing up that job when I've already invested time.
Yes, I totally empathize with you on this one!
Is it possible in its current form to have it in any branch? Can it at least stay in the gerrit?
Given their stance on license worship, I highly doubt that the owners of osmocom.org domain and infrastructure would allow license-violating stuff to be hosted anywhere under their domain. But I can give you hosting on freecalypso.org if you like - I am a proud pirate. :-)
M~
On Fri, Sep 11, 2020 at 08:55:53PM +0200, Xaver Zu wrote:
Please refrain from any personal attacks, we are guests here. People in this community have a right to their position. The GPL license seems to be on their side. I don't feel any frustration.
I want to solve factual problems objectively. Formal problems formally.
Denver please, if you have any doubts we could discuss about it.
I'm not sure what sort of doubts you're referring to off-hand - could you be a bit more specific as to the type(s) of doubts you're particularly interested in knowing more about?
Denver https://jmp.chat/
If I felt any doubts between the lines that you didn't have, then I apologize.
Do you think that this path is possible and correct? I still think so.
Xaver
pá 11. 9. 2020 v 20:59 odesílatel Denver Gingerich denver@ossguy.com napsal:
On Fri, Sep 11, 2020 at 08:55:53PM +0200, Xaver Zu wrote:
Please refrain from any personal attacks, we are guests here. People in this community have a right to their position. The GPL license seems to
be
on their side. I don't feel any frustration.
I want to solve factual problems objectively. Formal problems formally.
Denver please, if you have any doubts we could discuss about it.
I'm not sure what sort of doubts you're referring to off-hand - could you be a bit more specific as to the type(s) of doubts you're particularly interested in knowing more about?
Denver https://jmp.chat/
On Fri, Sep 11, 2020 at 09:11:45PM +0200, Xaver Zu wrote:
If I felt any doubts between the lines that you didn't have, then I apologize.
Do you think that this path is possible and correct? I still think so.
Yes, I think reimplementing libsdr.so under an AGPL-compatible license (such as GPLv3) is both possible and the correct thing to do. I haven't looked at libsdr.so at all, mind you, so I don't have any idea how long it will take. Hopefully it is not too long for you.
Denver https://jmp.chat/
Hi Xaver,
Please refrain from any personal attacks, we are guests here.
What personal attacks are you talking about? I offered you hosting on freecalypso.org for whatever materials you may have that aren't acceptable to osmocom.org for whatever reasons - that's an offer, not an attack, personal or otherwise. If you aren't interested in my offer, that is totally fine with me - spares me the work of setting things up for you - but please don't view me as any kind of attacker against you.
M~
Hi Xaver,
On Fri, Sep 11, 2020 at 08:09:16PM +0200, Xaver Zu wrote:
Is it possible in its current form to have it in any branch?
I would prefer not to have it in a branch of the official repository.
Can it at least stay in the gerrit?
I see no problem with having it in gerrit. I will add a related review comment that the patch was rejected due to licensing concerns. I don't think copyright prevents us from publicly documenting our development process and reltaed decisions.
Could I solve this with an open source (GPL) reimplementation of that library?
Yes. But, as other people stated, it is likely a significant effort, and there are other SDR devices that ship with fully open source software, sometimes not only software but even FPGA gateware or even open source hardware.
By all means, don't let me discourage you from implementing an open source alternative to that library. I just think there are other SDR devices available, which most likely have a much larger user base (at least in terms of FOSS projects like Osmocom, srsLTE, ...)
Regards, Harald
Yes. But, as other people stated, it is likely a significant effort, and there are other SDR devices that ship with fully open source software, sometimes not only software but even FPGA gateware or even open source hardware.
Which SDRs with PCIe do you remember? I know about XTRX. Master osmo-trx does not support it. And I know about limesdr-pcie, I'm not convinced that it makes sense to buy in this state of development.
I don't know about GPL compatible PCIe SDR with Analog Devices AD93XX family chip. Results of SDR based on the Analog Devices versus Lime chip are in favor of Analog Devices. I did a simple DSB modulation test. Analog Devices has a cleaner spectrum, better carrier suppression. This is what I noticed first on the spectrum analyzer.
Does anyone know of an SDR combining PCIe and an AD93XX chip that has the potential to be supported by osmo-trx? Does anyone know about such a CPRI for PCIe? I don't need it but libsdr.so supports it. I think this can be of benefit to the community.
Xaver
pá 11. 9. 2020 v 23:00 odesílatel Harald Welte laforge@gnumonks.org napsal:
Hi Xaver,
On Fri, Sep 11, 2020 at 08:09:16PM +0200, Xaver Zu wrote:
Is it possible in its current form to have it in any branch?
I would prefer not to have it in a branch of the official repository.
Can it at least stay in the gerrit?
I see no problem with having it in gerrit. I will add a related review comment that the patch was rejected due to licensing concerns. I don't think copyright prevents us from publicly documenting our development process and reltaed decisions.
Could I solve this with an open source (GPL) reimplementation of that library?
Yes. But, as other people stated, it is likely a significant effort, and there are other SDR devices that ship with fully open source software, sometimes not only software but even FPGA gateware or even open source hardware.
By all means, don't let me discourage you from implementing an open source alternative to that library. I just think there are other SDR devices available, which most likely have a much larger user base (at least in terms of FOSS projects like Osmocom, srsLTE, ...)
Regards, Harald --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Xaver,
On Sun, Sep 13, 2020 at 10:49:56AM +0200, Xaver Zu wrote:
Yes. But, as other people stated, it is likely a significant effort, and there are other SDR devices that ship with fully open source software, sometimes not only software but even FPGA gateware or even open source hardware.
Which SDRs with PCIe do you remember?
I was indeed thinking about LimeSDR-PCIe and XTRX.
I know about XTRX. Master osmo-trx does not support it.
well, neither does osmo-trx have for PCIe-SDR :P There were some patches submitted by Fairwaves to gerrit.osmocom.org (https://gerrit.osmocom.org/c/osmo-trx/+/15685) which received reasonable feedback, but Fairwaves did not have the time/capacity to follow-up and re-submit.
Given that you have demonstrated you can implement an entire osmo-trx backend and submit it to osmcoom and go through the review cycle, maybe you can convince Fairwaves that they should support you with a free or subsidized XTRX if you move their patches ahead and get them merged?
And I know about limesdr-pcie, I'm not convinced that it makes sense to buy in this state of development.
I'm not following the detailed status of this device. We do have one at sysmocom, but our focus has been on the USB-attached devices.
I don't know about GPL compatible PCIe SDR with Analog Devices AD93XX family chip.
I'm not aware of any, but I'm not the expert on available SDR hardware, to be honest.
Results of SDR based on the Analog Devices versus Lime chip are in favor of Analog Devices.
That reflects the general impression I get from many people so far.
Does anyone know of an SDR combining PCIe and an AD93XX chip that has the potential to be supported by osmo-trx?
Does anyone know about such a CPRI for PCIe? I don't need it but libsdr.so supports it. I think this can be of benefit to the community.
The main problem regarding CPRI interfaces is that there are no CPRI radio heads with publicly documented "command and control" interfaces. While the I/Q sample formats on CPRI/eCPRI are standardized, the command+control is not. So unless somebody reverse engineers those interfaces within CPRI, there will not be any radio head you can use.
And without any usable radio head, why would anyone build a CPRI PCIe interface card.
Some people within Osmocom had started to investigate commercially available CPRI radio heads e.g. from Ericsson, but I think it's primarily a "lack of resources / contributions" situation. Several people in Osmocom do have the equipment and even purchased some R&S CPRI test equipment.
I'm sure if a radio head was available with (published or reverse engineered) command and control, people would be interested in building a PCIe CPRI interface. sysmocom might even be interested in contributing financially to such a development at such a point in time.
Regards, Harald
-
Denver Gingerich -
Harald Welte -
Mychaela Falconia -
Xaver Zu