5 ms·

Vulcain: A REST-Based Alternative to GraphQL

61 points by pimterry 7y ago

yodon 7y ago
This makes me so incredibly sad. The project is so exciting and so right. Fully REST compliant backend, designed to support access by either REST or GraphQL queries, and pairable with Mercure to have fully REST async push subscriptions. Full backwards compatibility with REST and full solving of modern API design problems. That's incredibly cool. And then you discover that it's AGPL licensed. Time to move on. So incredibly sad. All that brilliant design work, all that fantastic problem solving. Shipped with a license that in the commercial world really is the kiss of death and that simply isn't possible to get past the legal department of any company large enough to have a legal department. My sadness isn't just that those of us with legal departments can't use this, it's that adoption will be so slow that all that incredible work you put into this isn't going to receive the uptake and adoption it deserves.
- pimterry 7y ago
  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.
- kdunglas 7y ago
  Thanks for the feedback! I just added a section in the README to clarify things about the license: https://github.com/dunglas/vulcain#license-and-copyright https://github.com/dunglas/vulcain#license-and-copyright * proprietary software can implement the Vulcain specification * proprietary software can be used behind the Vulcain Gateway Server without having to share their sources * modifications made to the Vulcain Gateway Server must be shared * alternatively, a commercial license is available for the Vulcain Gateway Server
  - yodon 7y ago
    I get that you're trying, but legal is still going to look at the AGPL license and say nope, because that's the license and that what governs what is and isn't allowed. I respect what I think you're trying to do there, but it isn't actually going to work. AGPL is a total deal breaker. That's the first part. The second part is where you say "oh and there is a commercial license if you don't want to use AGPL" which leaves an incredibly bad taste in my mouth. Any time I see that on a project I think "got it. They are using AGPL as a fake open license, knowing no one will actually use it, so this is really just a paid commercial venture trying to make itself look open sourcey". You're killing your project with AGPL and not actually going to achieve your intents with it. There is a reason why MIT and Apache are the dominant open source licenses today. Projects need adoption to be successful. It they get adoption, they get PR's. No adoption = no PR's, AGPL or not. The work you're doing is too important to needlessly kill it like this.
    - kdunglas 7y ago
      > They are using AGPL as a fake open license Actually, AGPL is the only license respecting copyleft's spirit for network applications such as the Vulcain Gateway Server (https://www.gnu.org/licenses/why-affero-gpl.en.html https://www.gnu.org/licenses/why-affero-gpl.en.html). If big companies don't want to play the game for whatever legal reasons, that's on them. And... so there is the commercial license (even if I'm pretty sure I'll never sell a single one for Vulcain). If they really want to use it, they can pay (they pay for AWS, Windows, Sales Force... and a lot of other proprietary software after all). > knowing no one will actually use it MongoDB (among other big projects) is very popular, and has been licensed for a while with AGPL (and it wasn't even restrictive enough to prevent Amazon to predate them, but that's another topic). Also Ghostscript, ownCloud, nextCloud, SugarCRM... In the case of Vulcain, the protocol is what has most value (IMHO), and it is not licensed under AGPL. It's pretty easy to implement directly the protocol in an app server (if it is written in a programming language able to deal with HTTP/2 directly such as Go, Rust, C or Node). > so this is really just a paid commercial venture trying to make itself look open sourcey My goal when publishing free software isn't to help big companies making proprietary services to make even more money without giving anything back (MongoDB, Redis, ... stories). Thanks to AGPL, users not able to modify the software (lack of financial resources, time or skills) can still benefit from changes made by big companies. That's the goal of copyleft. If they don't want to play according to the copyleft rules, then ok, they can pay as for any other proprietary software. It looks like a fair deal to me. > The work you're doing is too important to needlessly kill it like this. I really appreciate, and I'll maybe consider switching to another license at some points if it's a real blocker. Mercure.rocks (another of my projects) use the same strategy (permissive spec, that anybody can implement, and AGPL implem) and so far it got both adoption (and PRs, even if, as for Vulcain, the main value is in the spec, the server is a tiny piece of software that doesn't require too much maintenance). For lower level stuffs (such as my PHP libraries), I use MIT because they are designed to build something bigger, not to be used as-is such as the Vulcain Gateway Server or Mercure.
- echlebek 7y ago
  You can just implement the specification yourself, and license it however you want. What's the problem exactly?
conradfr 7y ago
I hope it's better done than his other projects that, while impressive at first, are full of corner cases and incomplete documentation ... which is brilliantly convenient when you sell consultancy for them. (just speaking from experience, not a personal attack)
- kdunglas 7y ago
  All my projects are free software (including their docs). You are free to improve them, or to not use them, or as you stated to hire me or anyone else to do it for you. Anyway, I'm interested in hearing more about the corner cases and incomplete docs you stumbled upon, to fix/improve what can be done.
  - conradfr 7y ago
    We did all these things :) And I can attest you and your coworker were professionals. Sorry if my previous post was too negative. I can't be too specific though as I was more affected by this than directly involved.
    - kdunglas 7y ago
      Thanks then :)
- mrkurt 7y ago
  That sounds an awful lot like a personal attack.
reilly3000 7y ago
I really like that syntax. It seems to have been well considered. I don't have a good understanding of how widely supported http/2 is, but I'm happy to see it implemented productively here.
- pimterry 7y ago
  Can't speak for client libraries, but for browsers 95% of real users in the wild support it: https://caniuse.com/#feat=http2 https://caniuse.com/#feat=http2
watersb 7y ago
I don't know much (no longer employed in software development) about the use cases. But I just skimmed some of these HN comments and I'm impressed by @kdunglas engaging in conversations here. Thanks.

61 points by pimterry 7y ago

This makes me so incredibly sad. The project is so exciting and so right. Fully REST compliant backend, designed to support access by either REST or GraphQL queries, and pairable with Mercure to have fully REST async push subscriptions. Full backwards compatibility with REST and full solving of modern API design problems. That's incredibly cool. And then you discover that it's AGPL licensed. Time to move on. So incredibly sad. All that brilliant design work, all that fantastic problem solving. Shipped with a license that in the commercial world really is the kiss of death and that simply isn't possible to get past the legal department of any company large enough to have a legal department. My sadness isn't just that those of us with legal departments can't use this, it's that adoption will be so slow that all that incredible work you put into this isn't going to receive the uptake and adoption it deserves.

pimterry 7y ago
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.
kdunglas 7y ago
Thanks for the feedback! I just added a section in the README to clarify things about the license: https://github.com/dunglas/vulcain#license-and-copyright https://github.com/dunglas/vulcain#license-and-copyright * proprietary software can implement the Vulcain specification * proprietary software can be used behind the Vulcain Gateway Server without having to share their sources * modifications made to the Vulcain Gateway Server must be shared * alternatively, a commercial license is available for the Vulcain Gateway Server
- yodon 7y ago
  I get that you're trying, but legal is still going to look at the AGPL license and say nope, because that's the license and that what governs what is and isn't allowed. I respect what I think you're trying to do there, but it isn't actually going to work. AGPL is a total deal breaker. That's the first part. The second part is where you say "oh and there is a commercial license if you don't want to use AGPL" which leaves an incredibly bad taste in my mouth. Any time I see that on a project I think "got it. They are using AGPL as a fake open license, knowing no one will actually use it, so this is really just a paid commercial venture trying to make itself look open sourcey". You're killing your project with AGPL and not actually going to achieve your intents with it. There is a reason why MIT and Apache are the dominant open source licenses today. Projects need adoption to be successful. It they get adoption, they get PR's. No adoption = no PR's, AGPL or not. The work you're doing is too important to needlessly kill it like this.
  - kdunglas 7y ago
    > They are using AGPL as a fake open license Actually, AGPL is the only license respecting copyleft's spirit for network applications such as the Vulcain Gateway Server (https://www.gnu.org/licenses/why-affero-gpl.en.html https://www.gnu.org/licenses/why-affero-gpl.en.html). If big companies don't want to play the game for whatever legal reasons, that's on them. And... so there is the commercial license (even if I'm pretty sure I'll never sell a single one for Vulcain). If they really want to use it, they can pay (they pay for AWS, Windows, Sales Force... and a lot of other proprietary software after all). > knowing no one will actually use it MongoDB (among other big projects) is very popular, and has been licensed for a while with AGPL (and it wasn't even restrictive enough to prevent Amazon to predate them, but that's another topic). Also Ghostscript, ownCloud, nextCloud, SugarCRM... In the case of Vulcain, the protocol is what has most value (IMHO), and it is not licensed under AGPL. It's pretty easy to implement directly the protocol in an app server (if it is written in a programming language able to deal with HTTP/2 directly such as Go, Rust, C or Node). > so this is really just a paid commercial venture trying to make itself look open sourcey My goal when publishing free software isn't to help big companies making proprietary services to make even more money without giving anything back (MongoDB, Redis, ... stories). Thanks to AGPL, users not able to modify the software (lack of financial resources, time or skills) can still benefit from changes made by big companies. That's the goal of copyleft. If they don't want to play according to the copyleft rules, then ok, they can pay as for any other proprietary software. It looks like a fair deal to me. > The work you're doing is too important to needlessly kill it like this. I really appreciate, and I'll maybe consider switching to another license at some points if it's a real blocker. Mercure.rocks (another of my projects) use the same strategy (permissive spec, that anybody can implement, and AGPL implem) and so far it got both adoption (and PRs, even if, as for Vulcain, the main value is in the spec, the server is a tiny piece of software that doesn't require too much maintenance). For lower level stuffs (such as my PHP libraries), I use MIT because they are designed to build something bigger, not to be used as-is such as the Vulcain Gateway Server or Mercure.
echlebek 7y ago
You can just implement the specification yourself, and license it however you want. What's the problem exactly?

conradfr 7y ago

I hope it's better done than his other projects that, while impressive at first, are full of corner cases and incomplete documentation ... which is brilliantly convenient when you sell consultancy for them. (just speaking from experience, not a personal attack)

kdunglas 7y ago
All my projects are free software (including their docs). You are free to improve them, or to not use them, or as you stated to hire me or anyone else to do it for you. Anyway, I'm interested in hearing more about the corner cases and incomplete docs you stumbled upon, to fix/improve what can be done.
- conradfr 7y ago
  We did all these things :) And I can attest you and your coworker were professionals. Sorry if my previous post was too negative. I can't be too specific though as I was more affected by this than directly involved.
  - kdunglas 7y ago
    Thanks then :)
mrkurt 7y ago
That sounds an awful lot like a personal attack.

reilly3000 7y ago

I really like that syntax. It seems to have been well considered. I don't have a good understanding of how widely supported http/2 is, but I'm happy to see it implemented productively here.

pimterry 7y ago
Can't speak for client libraries, but for browsers 95% of real users in the wild support it: https://caniuse.com/#feat=http2 https://caniuse.com/#feat=http2

watersb 7y ago

I don't know much (no longer employed in software development) about the use cases. But I just skimmed some of these HN comments and I'm impressed by @kdunglas engaging in conversations here. Thanks.