11 Sep
2020
11 Sep
'20
5:13 p.m.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
11 Sep
11 Sep
7:07 p.m.
New subject: Support for new SDR devices
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~
8:09 p.m.
New subject: Support for new SDR devices
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(a)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~
8:23 p.m.
New subject: Support for new SDR devices
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/
8:36 p.m.
New subject: Support for new SDR devices
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~
8:49 p.m.
New subject: Support for new SDR devices
pá 11. 9. 2020 v 20:36 odesílatel Mychaela Falconia <
mychaela.falconia(a)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~
8:55 p.m.
New subject: Support for new SDR devices
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(a)gmail.com> napsal:
pá 11. 9. 2020 v 20:36 odesílatel Mychaela Falconia <
mychaela.falconia(a)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~
8:59 p.m.
New subject: Support for new SDR devices
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/
9:11 p.m.
New subject: Support for new SDR devices
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(a)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/
9:52 p.m.
New subject: Support for new SDR devices
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/
9:08 p.m.
New subject: Support for new SDR devices
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~
11 p.m.
New subject: Support for new SDR devices
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
13 Sep
13 Sep
10:49 a.m.
New subject: Support for new SDR devices
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(a)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(a)gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
> A6)
>
16 Sep
16 Sep
6:58 p.m.
New subject: Support for new SDR devices
Hi Xaver,
On Sun, Sep 13, 2020 at 10:49:56AM +0200, Xaver Zu wrote:
I was indeed thinking about LimeSDR-PCIe and XTRX.
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.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1326
days inactive
1331
days old
13 comments
4 participants
participants (4)
-
Denver Gingerich -
Harald Welte -
Mychaela Falconia -
Xaver Zu