Request for Permissive Relicensing

[rektide]

Hi zrm,

Would you consider licensing this under a more permissive license than AGPL? Even LGPL would be great. Or MIT, BSD, Apache, what-not.

Inability to derive networks or systems with Snow without releasing source to those networks or systems stands as a pretty imposing barrier to adoption. Changing to a more permissive license may provide some grease to help #1.

[fredjean]

I was considering playing with snow, but I now must reconsider.

I refuse to use or recommend any Affero GPLv3 licensed software. I can work around using a GPLv3 licensed software, but the AGPL is just too toxic and contagious to my taste.

[zrm]

Snow is a daemon, not a library. Independent third party applications don't have to be distributed under the same license just because they resolve key names or send packets.

[fredjean]

It's unfortunate. The AGPLv3 is extremely viral and the mere use of AGPLv3 licensed software over a network could trigger the viral clauses. See

For those who don’t know, the AGPL is an incredibly viral license that says that not only do you have to redistribute your code changes, as the GPL states, but you must also publicly release any code that connects to an AGPL piece of software over a network. I fear the day that an HTTP server is built using AGPL. Think about it. (from Why I Hate the AGPL ).

Ultimately, the license that you release software under is your choice, but it also has consequences. I certainly hope that you would reconsider this really poor licensing choice.

[zrm]

the mere use of AGPLv3 licensed software over a network could trigger the viral clauses.

Just because you read something on the internet doesn't mean it's true. In this case it happens to be the opposite of true.

Read Section 13 of the AGPLv3 for yourself.

[vyp]

@fredjean If someone modifies the AGPL HTTP server, and then hosts it so that it interacts through a network, then they have to provide that modified source code. That quote seems to suggest that only AGPL software can connect to the AGPL HTTP server, which afaik is not true. IANAL.

[bddap]

Hey @zrm. This is an awesome project.

I imagine Snow would be very useful as a statically linkable library.

[zrm]

You're not the first person to ask for that, but there are reasons it doesn't make a lot of sense.

The first is that much of the code is really to make it possible to use with existing unmodified software. If you're going to link a static library then you don't need to make a name resolution request to get a virtual IP address that gives the data back to your own application via privileged network operations, only to send it yourself using the transport protocol. You could just send it directly using the transport protocol.

The big components that might make sense as a library are the transport protocol and the distributed hashtable.

There is nothing particularly unusual about the transport protocol. The one in the published code is based on datagram TLS, which I dislike. There is work ongoing to replace it with something like the WireGuard protocol. But in either case if all you want is a general purpose transport protocol then you can already use Noise or a TLS library or a variety of other things that I would just be repackaging.

So that leaves the DHT. I can see how that might be useful for other applications, but there are also reasons to keep it as a daemon rather than a library even then. It's exposed to the internet so it's better to have it running as an unprivileged user and segregated off as much as possible from any other code. (The roadmap has the DHT split off into its own separate process even within snow.) Moreover, DHTs have non-zero overlay maintenance overhead, so running one copy per device that multiple applications can share is more efficient, and makes traffic analysis somewhat more difficult because then it isn't blatantly obvious which application is responsible for a DHT message (and the same is true for the transport protocol as well).

On top of that, the snow DHT is protocol-specific and the peer would then expect you to send transport data as encapsulated IP packets, which snow gets from the kernel via the tun interface but you would have to assemble yourself and then handle retransmissions etc. Whereas if all you want is a general purpose DHT like Kademlia, there are existing third party libraries for that as well.

So if you want the whole package then it's a daemon, not a library. If you want the individual components there are already various third party libraries that do those things.