Liberal licenses are alive and well for libraries but for finished and polished products expect more of this. People are tired of being free labor for hustlers and billion dollar companies.

“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.

NetMaker homepage says "backed by Ycombinator" so I doubt they are free labor.

I sympathize to some degree, but true OSS is an important distinction for many and should be highlighted.

I don't have much sympathy for that argument. AGPL (or dual-licensed AGPL + commercial) is the simple countermeasure for freeloaders. Most tech companies won't touch it with a 20-foot pole.

> Most tech companies won't touch it with a 20-foot pole.

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.

This phenomenon is mostly just GPL-phobia. Microsoft spent billions in the 90s to convince corporate legal that the GPL is "viral" in ways it is not. You could simply rename the license to something other than the letters G-P-L and this would go away.

Didn't seem to be such of a silver bullet for MongoDB, which used AGPL and still were forced to abandon it in favor of an even stronger version made by themselves (the SSPL, which is an AGPL on steroids).

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.

I'm surprised they went for the SSPL, though. Its terms are too vague about the distinction between hosting and just using, and also at the time I read this entry in HN about how it might actually be unenforceable anyway:

https://news.ycombinator.com/item?id=18301116

Thanks for pointing this out - a major negative for this project.

For now, Nebula is still my choice in this space.

Same here. Nebula might not be wireguard based, but it is open source and very stable.

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.

Why isn’t SSPL considered FOSS but AGPL is?

The short answer is SSPL has field-of-use restrictions, the AGPL does not.

SSPL is a bit more restrictive, but politics also have a lot to do with it. "Open Source" is just a term, technically anyone could call their license open source, but most people only consider a license open source if the OSI (a foundation) specifically approves it. Mongo tried and failed to get SSPL approved by OSI: https://blog.tidelift.com/what-i-learned-from-the-server-sid...

Interesting. According to the article, it seems like the biggest complaint was that Mongo was a for-profit company and couldn’t be trusted? I agree that for-profit companies can’t be trusted, but I’m not sure I agree with the statement “that’s not open source because the license was written by a for-profit company”.

That article is obfuscating why the license was going to be rejected by the OSI. The OSI has as part of their definition of open-source that there can be no field of use discriminators. It had nothing to do with the fact that it was drafted by a commercial company. OSI has approved plenty of licenses drafted by for-profit companies (e.g. Intel, IBM, Microsoft.)

https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

https://opensource.org/osd/

Thanks. That makes sense.

How come AGPL doesn't run afoul of #10 of the OSD definition, which is:

> 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.

[1] https://en.wikipedia.org/wiki/ADM-3A

That provision is intended to exclude licenses that say things like "you must show a modal GUI window crediting this software" which would exclude the software from being used in a server application, library or command-line interface. Or a clause like "you must provide a copy of this software on a zip-disk if asked", which over time would become increasingly hard to do.

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.

Hi! Netmaker here. At the time of this writing this is true, but we're making some licensing changes this sprint, which I think will make people very happy. We started with SSPL just because it's much easier to go from more restrictive to less restrictive, as opposed to the alternative.

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.

IANAL. I'm afraid you have it the other way around. It is easier to switch from permissive licenses (MIT / 3BSD) to compatible restrictive license (MPL / xGPL) than vice versa (xGPL to MPL / MIT) without a CLA.

Glad you're going Apache, though.

We do have a CLA, and put it in place for this very reason. It is more complex legally, but I meant more in terms of the community. Better to make people happy by going less restrictive over time then to start out with Apache and switch to something more restrictive and upset a bunch of people.

That's awesome! Glad it's a priority.