> Docs are written for self-hosters. These are all good signs.
Except at the time of writing, netmaker isn't FOSS: https://github.com/gravitl/netmaker/blob/16d5b5807/LICENSE.t...
Except at the time of writing, netmaker isn't FOSS: https://github.com/gravitl/netmaker/blob/16d5b5807/LICENSE.t...
However, several months ago we moved all of the client-side code to Apache-2.0, and are about to make the server-side code FOSS-compatible.
Glad you're going Apache, though.
For now, Nebula is still my choice in this space.
Though, I have to say that if you are using Nebula within a LAN it sometimes takes minutes for two nodes to realize they are within each other's reach. In the mean time, they talk through the lighthouse which can severely affect performance.
“Thanks for all the work, we’ll take that and put it behind a paywall and monetize it for you and not give you anything.”
People other than the author have a huge advantage when it comes to monetizing: they can focus only on that. The authors have to focus on creating while others can focus only on marketing.
I sympathize to some degree, but true OSS is an important distinction for many and should be highlighted.
I'm not sure if there are more such cases, but clearly with this one, AGPL was not enough.
I guess the issue is: if you have freeloaders, who are making all the money you would need to keep the OSS project alive, AGPL doesn't help you in any way. They are free to get the code as-is, run it, and serve their customers. Not sure why everybody suggests AGPL+Commercial as the perfect solution, it doesn't seem to solve anything for that case.
This!, in my experience lawyers will deny the use of AGPL software, even when there is no risk (from my point of view). Many companies have already a list of blessed licenses, and AGPL is not part of the ones I'm aware of.
https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
> 10. License Must Be Technology-Neutral
> No provision of the license may be predicated on any individual technology or style of interface.
Under AGPLv3 if I have AGPLv3 code on a computer and users can interact with it the requirements depend on the technology used by the users to interact with the program.
It had a provision that only applies to users who are "interacting with the remotely through a computer network".
So...if my users are at the same location as the server and interacting through a command line interface on serial terminals those provisions do not apply.
I want to add a few more terminals in a nearby room but don't want to actually run serial lines from all of them to the server. Instead I run ethernet to the room the new terminals will be in, and at each terminal place an RPi with the terminal connected to the RPi and the RPi connected to ethernet. The RPi runs software that connects to the server via ssh and then exposes that ssh session on the terminal so they can use the command line interface to that AGPL program.
Now the users are interacting with the server via a computer network and so those provisions of AGPL might now apply, depending on whether or not this counts as interacting "remotely".
Same thing but now I provide an app that users can run on their phones that that makes a hard coded connection to my server and runs a terminal emulator over that to a terminal session on the server, where the users can use the AGPL program. There doesn't seem any question that this is now definitely remote, and it is over a computer network, so those AGPL provisions now definitely apply.
And so we have essentially one thing, users using a terminal interface to interact with an AGPL command line program on my server, where what license provisions apply between me and any given user depends on just what technology is used to carry their typed text between their keyboard and my server, and to carry the program output text between my server and their display.
The AGPLv3 is not predicated on a particular technology or interface so it doesn't run afoul of this. You can use it in networked software, or un-networked software. If a license said something like "you cannot use this for software that users interact with over a network" then it would violate this principle.