
Vulcain: A REST-Based Alternative to GraphQL - pimterry
https://github.com/dunglas/vulcain
======
yodon
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.

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

~~~
curryst
> 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).

If I were looking at using this, it's somewhat of a show-stopper for me not
because I think that my company wouldn't want to pay for it; it's that the
procurement process is so painful that it becomes almost not worth it for the
limited scope of use.

I think a lot of people miss one of AWS' greatest selling points: I go through
procurement once to get authorized to use AWS, and it then opens up a whole
cache of services I can utilize. Things with a wide range of functionality are
worth fighting with procurement over; things that implement a single function
start to kick in cost-benefit questions over whether I can get by with the
functionality provided by MIT or Apache licensed projects, or if I can re-
implement the portions I'm interested in.

> In the case of Vulcain, the protocol is what has most value (IMHO), and it
> is not licensed under AGPL.

I shudder at the thought of trying to convince legal of this. That may be your
interpretation or goal, but Legal is likely going to take the broadest
possible interpretation of the licensing. I'm not a lawyer, I have no context
to discuss who's right here, but my experiences with legal have been to always
assume that they will take an extremely conservative approach (as is their
job). That being said, Mongo does do the same thing, and the surrounding
discussions seem to agree that using Mongo's API does not make your software a
derived work.

The AGPL introduces a risk that someone, maybe an intern or someone 3 years
later who doesn't know the licensing context around the AGPL software, will do
something that makes internal applications a derived work. Even denoting what
makes something a "derived work" gets into murky territory that, afaik, has
not entirely been legally tested in court.

It has far less to do with being unwilling to contribute the changes back to
upstream, and more to do with a fear of the risk that someone will
accidentally violate the segregation between our applications and the AGPL'ed
one, and suddenly all of our proprietary code is under the AGPL because one
application violated that boundary. Which is legitimate fear if your codebases
are tightly coupled (i.e. this app used Vulcan as a library, and that app
links to this library that almost all of our applications use, so now it's all
under the AGPL). The problem is not contributing changes to Vulcan upstream,
it's the risk of the license infecting proprietary software.

This is super cool, and I am definitely going to dig into this for personal
projects. I really appreciate the work you put in, and you open sourcing this.
The licensing is entirely up to you, and I'm going to poke around in it either
way; but it is a killer for trying to use it in enterprise-y environments.

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

------
conradfr
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
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
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
Thanks then :)

