PyHSS / pyhss-tool
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@osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@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
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/
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@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/
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@osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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!
participants (4)
-
Alexander Couzens -
Harald Welte -
Keith -
Nick Jones