graphql-schema-registry
graphql-schema-registry copied to clipboard
tot-ra
Moving to GraphQL Federation V2
what would that change mean for the license? I believe in v2, Apollo changes their license from MIT, would that mean that this library is also no longer MIT? cc @tot-ra
what would that change mean for the license? I believe in v2, Apollo changes their license from MIT, would that mean that this library is also no longer MIT? cc @tot-ra
That's a good question. My understanding is that there is no impact, as long as the schema registry is not offered as a managed service. My understanding is based on these lines from the Apollo license. So as long as the schema registry is hosted privately, I believe it's fine. I might have missed other details though.
It may be true, but if schema-registry currently is under MIT then there are no apollo restrictions and then we start using dependency that has custom licenses / limitations, then we can cause a legal incident where someone builds commercial platform based on MIT license promise. Needs some kind of a workaround
dependency that has custom licenses / limitations, then we can cause a legal incident where someone builds commercial platform based on MIT license promise. Needs some kind of a workaround
Any ideas? Would extracting supergraph/federation functionality in some kind of plugin be enough? What I'm thinking is that the registry could come out of the box with a federation v1 plugin, Apollo federation v1 being still MIT licensed. Having a minimalistic plugin architecture in place would allow folks desiring Federation v2 to implement a plugin of their own, outside of the main registry codebase, thus avoiding legal issues. The downside is that federation v2 does bring some changes in terms of functional tests, as can be seen in the PR. Not sure how those would be handled.
The other approach I see would be a license change to avoid any liabilities, but I suspect this won't be a popular option! I'm not too much of a fan of a project changing license midway, although I understand why Apollo has taken this path.
Anyhow, let me know what you think.
I'll talk to our legal team, but I think we could have indeed a plugin-like system where v1
import { composeAndValidate } from '@apollo/federation'; would be replaced by an internal HTTP request to a configureable target (a separate docker container).
By default it could include v1 federation.. or maybe our custom validator, keeping MIT. And with ENV var, we could direct it to a v2 federation composition plugin. Then that plugin could have own elastic license, compatible with apollo. Basically moving responsibility of licenses on the end customer when he starts up containers Functional tests thus could depend on that env var.
That would make our setup somewhat more complex 🤔
I think we may need a small guide how to do the migration from v1 to v2 too 🤔
For example I had errors like:
"message": "[service-xxx] On type \"Note\", for @key(fields: \"id\"): field Note.id cannot be included because it has arguments (fields with argument are not allowed in @key)"
//KEY_FIELDS_HAS_ARGS
I assume its related to subgraph update step https://www.apollographql.com/docs/federation/federation-2/moving-to-federation-2#step-3-update-individual-subgraphs
There are use cases where Federation v1 should have raised errors but did not, and now Federation v2 properly detects them. We had such an issue in one of our own subgraphs. The following mentions a few of these use cases:
https://www.apollographql.com/docs/federation/federation-2/backward-compatibility/#breaking-changes
It looks to me like the example you mentioned probably falls into this category.
Will come up with an updated PR testing the plugin approach. Would the plugin need to be HTTP based? I'm thinking everything could be in code, with the Federation v2 version loaded dynamically somehow, as long as the Federation v2 code is separate from the main codebase. Federating schemas using either the v1 composeAndValidate() function or the v2 composeServices() is already pretty slow. Going over HTTP would only make it slower.
we just submitted our initial try to solve this in Hive, maybe you can use that as inspiration: https://github.com/kamilkisiela/graphql-hive/pull/373
I emailed to Apollo ( I guess @abernix ) & @debergalis , maybe they can clarify their stand on this
So Matt's reply about licensing includes:
It's fine to distribute code that links to or references our ELv2 composition library. You can use any license you like for that code, including MIT.
The ELv2 license stays attached to our code, so it would not be okay for you (or anyone else who downloads the project) to run it as a managed cloud service for a third party. That's the main idea behind ELv2, exactly as you say.
The other thing to note — if you distribute the federation code or a fork of it, or a binary build that includes federation or a fork, then you just need to preserve our copyright and ELv2 license in that distribution (along with any other licenses you're using). I don't think you are distributing federation code but I include it for completeness.
So based from this, looks to me like we can merge v2 as is, without any workarounds and its up to the client to understand the licensing limitations of transitive dependencies (composition library) and not violate it.
However, I am not so sure about docker image. I think that can't be considered referencing and I'll need to include Apollo's copyrights in docker hub README
That's great news @tot-ra! Thanks for looking into this. I'll leave you to review the PR, if you think any change has to be made, let me know.