Sudden insight this morning that while the GPL is activated upon distribution, the AGPL is activated upon execution (with any networked interaction involved in that execution).
While I don't think this is an impossible thing to manage, I do think it means that compliance is more difficult with the AGPL... if you are already distributing software, it's not generally hard to distribute source along those same channels. If you're just executing software and having an interaction with another network participant, you might not necessarily have a similar arrangement to do a distribution... you might not even really know what you're running. (That sounds like an odd statement, but "finding" the correct source to distribute in AGPL'ed applications is an unsolved problem.)
While I think this can be overcome with server->client interactions, with some difficulty, I'm still not sure that most client->server interactions, where the client is running AGPL'ed code, can be easily handled. For this reason, I've been avoiding using the AGPL for software which might be incorporated with client code. I find it worrying when compliance may become overly difficult.
I'd like to be wrong about these things!
Claes Wallin (韋嘉誠) likes this.
Claes Wallin (韋嘉誠) shared this.
My most recent project, keysafe, is AGPLed, and the client and server are part of the same program, and a large amount of code is reused between them including http request generation/parsing, object queuing/storage, proof of work generation/checking, data types, and serialization.
So, I hope that there's not really a good reason to avoid using AGPLed code if it could end up running on the client. That would make development significantly less efficient when there's so much opportunity for server and client to share code.
Or it would limit the AGPLed parts to such a thin shell around the shared code that it might not be much of a barrier to creating a non-AGPLed server implementation. If keysafe's shared code was GPLed and only the server-specific code were AGPLed, a simple non-AGPLed server using the GPLed code be implemented by writing only 2 trivial functions; around 10 lines of code.
Christopher Allan Webber likes this.
@joeyh @Charles ☕ Stanhope Note that you could call my post "spreading FUD": I don't have a real tested case of these things. But in moving towards implementing the systems I'd like (which move closer to peer to peer + actor model over time) I've thought about these concerns a lot.
I like the AGPL a lot, and so I debated quietly and cautiously not using it for the project I wanted to, or to discuss it publicly, or just discuss it privately. But I feel like private conversation hasn't gotten me far enough over time, so here's me kicking the shins or tires or something. Hopefully better than kicking the can down the road...
Christopher Allan Webber at 2016-09-27T14:32:09Z
Claes Wallin (韋嘉誠), Charles Stanhope likes this.
Of course, other projects will vary. My use of AGPL In git-annex is confined to its webapp, and there's still a significant amount of code there, that would take lots of effort to reimplement. There's very little chance any of the AGPLed code there would ever end up in a client either, and if
some part of it did, I'd relicense it GPL in any case.
Still, it seems a shame if AGPL could only usefully be applied to that style of client-server app, and not to ones that have a more svelte design, like keysafe, or presumably what @Christopher Allan Webber is doing with actors.
@joeyh Note that I don't think that the AGPL can't apply to these systems... I'm just not sure of what the compliance implications are! :)
Christopher Allan Webber at 2016-09-27T16:57:58Z
Claes Wallin (韋嘉誠) likes this.