Just some comments and questions that may be helpful from me, in
case you’re interested:
1. Why did you pick GPLv3 as the license? Is this an ARDC requirement or a decision independently made for the Portal? Is there any chance to reconsider and pick a license like MIT, BSD, or Apache 2? I feel like the restrictions that GPL (especially v3) imposes are unnecessary.
We're open to different open source licenses. Why would you choose MIT, BSD, or Apache 2 over GPL?
GPL is applying restrictions on the code that prevent certain use. The other licenses listed above actually allow for free use and distribution of the code. They do not pose any significant limitations. With a GPL license, if you’re interested in contributing to the code or making a fork of the software, you can either do it privately, or you’re forced to publish it under the same license. This can lead people into keeping their forks private. Moreover, if a project uses code from a GPL project, even in part, it needs to be released under the GPL as well (unless it includes the code in the form of a library), which can limit reusability of the code by others. (I have seen and heard many stories on that, and it’s not clear to which degree this is true, e.g. if linking the code is okay or not, but it can expose you to risk).
Moreover, for a lot of professionals, especially outside the US, it can be difficult or may require explicit approval from their employer to contribute to such software, or it may not be allowed outside the scope of their work, due to intellectual property rights. Some companies for example allow you to contribute to any OSS under a certain license list, and almost always the three ones above are included, and almost always GPL is explicitly not included.
There’s a large debate about enforceability, and some of these areas are not well understood or defined, and that’s why typically companies that care about the legal risk tend to just avoid any exposure.
A lot of modern programming languages such as Rust and Go try to have a culture of Apache 2 which is the recommended license (and has a very helpful patent provision) and most of the libraries choose a license in the list above (called permissive). This helps ensure GPL-free software which they probably consider an important point.
Here’s an interesting article I just found:
https://medium.com/@henvic/opensource-and-go-what-license-f6b36c201854 — 87% of Go code on GitHub is licensed under permissive licenses. Around 75% of any software is licensed under permissive licenses. It also covers a lot of important points on why you can choose one vs the other. However, a modern typical practice seems to be a dual Apache 2 + MIT option, but it may be too much for the Portal. Any one of the two is fine. I think there’s some bias in the article, so keep that in mind while reading.. ;)
Of course, it should be mentioned that there are very large and successful projects that are using GPL, but some are too big to be ignored, and this may be the reason. The most popular is Linux, that is licensed with GPL, but even that does not use GPLv3, but GPLv2, as Linus Torvalds expressed a dislike towards the changes introduced in the 3rd version.
My main point, and why I always prefer permissive licenses, is that you remove the potential for legal risk / gray zones, and you release software that is truly free, without imposing restrictions to anyone. This, however, may not be something everyone wants, but I don’t see a reason why we should not do that.
Finally, as something unrelated to the Portal code, but a practice I see more and more lately: software companies release the “Community Edition” under GPL, and the “Enterprise Edition” as a paid license. That way they use the GPL to prevent their competitors from forking the code, or doing any development, and they maintain the sole right to sell this code (that people outside the company may contribute). There’s also a recent trend it seems for a certain Cloud provider to find OSS with permissive licenses, and offer it "as a Service”, directly competing with the company or team behind it, that also attempts to do the same thing. These companies have been forced to restrict their code to remain financially viable, but still chose to stay away from the GPL.
4. I would like to see WebAuthn for Security Keys with support of multiple, e.g. 8-16 keys, and not single-key only like some services. The web also seems to be moving to a passwordless future, with support for Passkeys already landed in browsers and OSes in desktop + mobile. Integrating WebAuthn for 2FA and Passkeys for passwordless login is very similar. My colleague Adam has written a very good technical post on how to implement these standards securely in case you’re interested: https://www.imperialviolet.org/2022/09/22/passkeys.html <https://www.imperialviolet.org/2022/09/22/passkeys.html> . I would also try to avoid any insecure practices like security questions to recover an account. I don’t know if I would pick SMS 2FA for a new project, although it’s better than nothing. Just make sure you don’t fall back to SMS e.g. if Security Keys / TOTP doesn’t work. I think with e-mail 2FA support the SMS option isn’t needed. People without a smartphone would still need e-mail access to login, so I don’t think it is excluding people if you do not offer it. Just be careful with WebAuthn: it is domain dependent. The blog post I link to explains this well, and also what happens if the domain of the Portal changes.
Thanks, this is noted. Ideally we provide multiple options for 2FA.
That’s a good and inclusive choice and I support it. I would just want you to avoid the legacy of SMS 2FA in a brand new system :)
9. Can you not delegate $callsign.ampr.org <http://callsign.ampr.org> to your own servers anymore? Or is this still done manually via a ticket?
The items described in the feature requirements doc are not live, so please continue to use existing processes until we make the transition to the new Portal. Ideally this process of transitioning to the new portal, led by our forthcoming Technical Director, will not be abrupt and have sufficient warning for changes. I do not see any major release for the new portal happening until 2023 (ideally early 2023, but no promises + more scoping needed.)
Yes, of course, by “anymore” I was referring to the new system, but it was not clear enough. I was informed that this isn’t possible today anyways, so I apologize for the mistake. It seems that nothing is changing with the new requirements.
13. I would like to see IPv6 support explicitly mentioned as a requirement, both for the software, as well as the service. The functionality (assignments, allocations) depends on what the plans and needs of ARDC are, but being able to use the Portal fully in an IPv6-only network is something I believe should be there regardless.
This may be a whole second project, combined with a longer discussion around whether ARDC should actually manage an IPV6 block. We see cases for and against it, but ultimately, we need to make sure that our existing address space is better managed and utilized before taking on more. That said - your comments are noted.
I agree, and that’s why I’d like to focus on ensuring the portal is accessible over IPv6 at least, regardless of whether or not this project will happen, and whether ARDC will ever have to manage IPv6 addresses. It’s always good to be able to use the current IP version to manage the legacy one ;)
Antonis