5 ms·

It's not actually my project, I saw in on Twitter: https://twitter.com/dunglas/status/1182685694306721798 https://twitter.com/dunglas/status/1182685694306721798

It's not actually my project, I saw in on Twitter: https://twitter.com/dunglas/status/1182685694306721798 https://twitter.com/dunglas/status/1182685694306721798 That said, while I see how this is a PR challenge, I'm not sure it needs to be a practical problem. I believe AGPL here would only be relevant to the gateway server itself. The formal spec is intended to be permissively licensed, and you can easily implement the design in any language you choose. If this gets popular, liberally licensed clients & servers will appear pretty quickly. Some discussion from the author here: https://twitter.com/PierreJoye/status/1182885929414848513 https://twitter.com/PierreJoye/status/1182885929414848513

yodon 7y ago
While I understand and hear his stated intent in the twitter post, corporate legal departments are going to look at the actual written license and say no. I also hear your point that other more permissive code bases can be written to reimplement the spec but what a terrible waste of resources that would be. By going AGPL he's basically making all the work he did to implement it a throw-away effort that will need to be superseded by an MIT or BSD or Apache-licensed implementation. I get the intent of AGPL, he wants updates committed back to the codebase. The problem is that corporate legal departments that are fine with PR's to MIT projects won't let you even touch an AGPL project to begin with. As with so many things involving social contracts, force is not always the best way to achieve the ends one desires. If I'm using a project and I make a fix or improvement, I want it committed into the main release branch because that makes my life easier the next time I need to pull updates from master. A quick tally of license popularity trends over the past decade demonstrates enlightened self interest like this is far more effective at motivating developer behavior around PR's than the AGPL ever was, without adding any terms that cause legal departments to block adoption.

yodon 7y ago

While I understand and hear his stated intent in the twitter post, corporate legal departments are going to look at the actual written license and say no. I also hear your point that other more permissive code bases can be written to reimplement the spec but what a terrible waste of resources that would be. By going AGPL he's basically making all the work he did to implement it a throw-away effort that will need to be superseded by an MIT or BSD or Apache-licensed implementation. I get the intent of AGPL, he wants updates committed back to the codebase. The problem is that corporate legal departments that are fine with PR's to MIT projects won't let you even touch an AGPL project to begin with. As with so many things involving social contracts, force is not always the best way to achieve the ends one desires. If I'm using a project and I make a fix or improvement, I want it committed into the main release branch because that makes my life easier the next time I need to pull updates from master. A quick tally of license popularity trends over the past decade demonstrates enlightened self interest like this is far more effective at motivating developer behavior around PR's than the AGPL ever was, without adding any terms that cause legal departments to block adoption.