22 Mar
2024
22 Mar
'24
8:55 p.m.
Hi all,
While working with open5gs + kamailio, one traditionally always needed two HSS:
* the open5gs one with its mongodb and nodejs hell
* the FHoSS one for the kamailio IMS core
For some time there's now PyHSS, which supports both EPS and IMS subscriptions, which
is of course nice. docker_open5gs meanwhile also has switched to using it as default.
The big problem is that it doesn't actually state which license it is
under, which makes it legally impossible to [re]distribute it, or to even make a fork
of the repository, as that would be a violation of copyright. At least German users
are abel to legally use it, as under German copyright law you don't need
a license from the copyright holder to use a program that you have obtained legally.
In order to automatize the steps described in the open5gs_docker to create
subscribers, I've just hacked up a small tool, see
https://gitea.osmocom.org/laforge/pyhss-tool/src/branch/master/pyhss-tool.py
Using that tool, it's as easy as
pyhss-tool.py subscriber-create --imsi 001011111111111 --msisdn 1111 --k
000102030405060708090a0b0c0d0e0f --opc 00000000000000000000000000000000
or
pyhss-tool.py subscriber-delete --imsi 001011111111111
to add/remove subscribers. You will still need to manually create the
internet and ims APNs via the REST interface; I'll probably also add
that capability to the tool.
Once it's a bit more tested, I also would like to contribute it
upstream, at least once that is possible. To do that I'd have to make a
pull request, and making that pull request requires me to create a fork,
which is a copyright violation. wtf.
If that legal situation has cleared up, it might be worth considering either adding
native GSUP support to PyHSS (so it can be used by osmo-{msc,sgsn}, or to have
a converter like osmo_gsup2dia (the inverse of the existing osmo_dia2gsup).
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
22 Mar
22 Mar
11:28 p.m.
Hi Harald,
While working with open5gs + kamailio, one
traditionally always needed two HSS:
* the open5gs one with its mongodb and nodejs hell
* the FHoSS one for the kamailio IMS core
for the open5gs I'm using for the epdg open5gs-dbctl (a shell script to talk to
mongodb).
I've added some lines to set the msisdn.
For some time there's now PyHSS, which supports
both EPS and IMS subscriptions, which
is of course nice. docker_open5gs meanwhile also has switched to using it as default.
Do you know which parts are missing in the open5gs-hss?
Once it's a bit more tested, I also would like to
contribute it
upstream, at least once that is possible. To do that I'd have to make a
pull request, and making that pull request requires me to create a fork,
which is a copyright violation. wtf.
I also noticed the missing license information on pyhss even the source is public.
Best Regards,
lynxis
--
- Alexander Couzens <acouzens(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
24 Mar
24 Mar
9:24 p.m.
Sounds bizarre.
I really don't know anything about it, but I do remember a call with
nick [at] nickvsnetworking.com some years back and everything about that
conversation was reasonable.
Isn't it simply a case of reaching out and asking for the license terms
to be clarified, I'd be surprised if the response were to be silence or
even negative.
(OK I really must learn to stop being surprised by what I'm surprised
about, they way the world is.)
Is this simply some situation where Nick has not understood the
conundrum in which the German law-abiding citizen is placed due to a
lack of explicit statement of licensing terms?
Also, (and here I thought I understood correctly), but you may know
better; Github's terms of service:
5. License Grant to Other
Users<https://docs.github.com/en/site-policy/github-terms/github-terms-o…
Any User-Generated Content you post publicly, including issues,
comments, and contributions to other Users' repositories, may be viewed
by others. By setting your repositories to be viewed publicly, you agree
to allow others to view and "fork" your repositories (this means that
others may make their own copies of Content from your repositories in
repositories they control).
If you set your pages and repositories to be viewed publicly, you grant
each User of GitHub a nonexclusive, worldwide license to use, display,
and perform Your Content through the GitHub Service and to reproduce
Your Content solely on GitHub as permitted through GitHub's
functionality (for example, through forking). You may grant further
rights if you adopt a license
<https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository#including-an-open-source-license-in-your-repository>.
If you are uploading Content you did not create or own, you are
responsible for ensuring that the Content you upload is licensed under
terms that grant these permissions to other GitHub Users.
Are German user's of Github somehow excluded from this global right to fork?
I know Mexico updated copyright law over the last few years, but maybe
this implicit exclusive copyright if not claimed is not the same here, I
could ask.. but I think best to reach out, no?
k/
11:19 p.m.
G'day folks,
Chiming in here as I've been slack responding to the Github issues:
PyHSS project started off as a little side project when experimenting with
IMS and I never expected it to gain the traction it has, and it's great to
see more folks using it!
Full credit to Dave who has done a fantastic job in evolving PyHSS into
something production ready, and we're in the process of adding support for
the full M3UA/TCAP/MAP stack to allow PyHSS to function as an HLR, of
course GSUP support would be welcome.
The code has always been intended to be open source, hence being public on
Github from the start, but I've never really done my homework on the most
appropriate license for the code. I'll work out what license suits best and
update the Github accordingly, so everyone can submit PRs.
Cheers,
Nick
On Mon, 25 Mar 2024 at 08:24, Keith <keith(a)rhizomatica.org> wrote:
Sounds bizarre.
I really don't know anything about it, but I do remember a call with nick
[at] nickvsnetworking.com some years back and everything about that
conversation was reasonable.
Isn't it simply a case of reaching out and asking for the license terms to
be clarified, I'd be surprised if the response were to be silence or even
negative.
(OK I really must learn to stop being surprised by what I'm surprised
about, they way the world is.)
Is this simply some situation where Nick has not understood the conundrum
in which the German law-abiding citizen is placed due to a lack of explicit
statement of licensing terms?
Also, (and here I thought I understood correctly), but you may know
better; Github's terms of service:
5. License Grant to Other Users
<https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#5-license-grant-to-other-users>
Any User-Generated Content you post publicly, including issues, comments,
and contributions to other Users' repositories, may be viewed by others. By
setting your repositories to be viewed publicly, you agree to allow others
to view and "fork" your repositories (this means that others may make their
own copies of Content from your repositories in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant
each User of GitHub a nonexclusive, worldwide license to use, display, and
perform Your Content through the GitHub Service and to reproduce Your
Content solely on GitHub as permitted through GitHub's functionality (for
example, through forking). You may grant further rights if you adopt a
license
<https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository#including-an-open-source-license-in-your-repository>.
If you are uploading Content you did not create or own, you are responsible
for ensuring that the Content you upload is licensed under terms that grant
these permissions to other GitHub Users.
Are German user's of Github somehow excluded from this global right to
fork?
I know Mexico updated copyright law over the last few years, but maybe
this implicit exclusive copyright if not claimed is not the same here, I
could ask.. but I think best to reach out, no?
k/
26 Mar
26 Mar
6:48 p.m.
Hi Nick,
thanks for your follow-up!
On Mon, Mar 25, 2024 at 10:19:34AM +1100, Nick Jones wrote:
The code has always been intended to be open source,
hence being public on
Github from the start, but I've never really done my homework on the most
appropriate license for the code. I'll work out what license suits best and
update the Github accordingly, so everyone can submit PRs.
Thanks a lot for taking care of this. Let me know if you need any help regarding
FOSS licensing. As you may or may not know, it's a topic I've had a lot of
contact
with.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:04 p.m.
Hi Keith,
On Sun, Mar 24, 2024 at 03:24:14PM -0600, Keith wrote:
Also, (and here I thought I understood correctly), but
you may know better;
Github's terms of service: [...]
Are German user's of Github somehow excluded from this global right to fork?
I was unaware that github mandated such a license, and was basing my previous
assessment simply on copyright law. So indeed, if any public repo on github
implicitly comes with that license, it seems forking the repository is permitted.
Note that this only means "use display and perform". It does not include a
permission
to change the code, so doing that in order to submit a PR requires an actual license
beyond the github-implied one.
but I think best to reach out, no?
I was under the assumption that
https://github.com/nickvsnetworking/pyhss/issues/143 from June 2023 and
my more recent update on it would have been reaching out. In my world
it's generally a no-go to send unsolicited personal e-mail to
maintainers and alwys use the respective channel (issue tracker, mailing
list, forum, whatever).
In any case, Nick has kindly responded to it here on the list, so let's
hope the situation will be resolved soon.
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9:36 p.m.
On 26/03/2024 13:04, Harald Welte wrote:
In my world
it's generally a no-go to send unsolicited personal e-mail to
maintainers and alwys use the respective channel (issue tracker, mailing
list, forum, whatever).
Interesting, For me, with the amount of really unrelated and truly
unsolicited mail going around, I don't mind getting an email from people
who have a genuine project related issue, especially if that person
makes it clear that they sincerely believe that what they are bringing
to my attention, needs attention. I actually kind of think that is what
an email address in part, is for.
I also know that not everybody is paying attention to posted issues or
comments on issues, which by times, can be as bad as plain old SPAM.
Also possible that there are people who don't want to or cannot for some
other reason write on a specific platform's issue system. Anyway, I just
see all this, including the rights mess as symptomatic of how unwell our
competitive capitalist society is. Hopefully it doesn't last too many
more decades. :-)
In any case, Nick has kindly responded to it here on the list, so let's
hope the situation will be resolved soon.
Yes, that's the important bit!
516
days inactive
516
days old
6 comments
4 participants
participants (4)
-
Alexander Couzens -
Harald Welte -
Keith -
Nick Jones