GraphQL has driven much of the conversation around modern API web design, and for good reason — it’s powerful, extensible, and very useful for high data query applications. The ability to request data in a predetermined, knowable format, and the ability to collate endpoints into a single external point, has made GraphQL something that powers some pretty huge projects.

Unfortunately, reliance on a near-ubiquitous format comes with a negative – when a change is made to GraphQL, its effects are wide-ranging and significant. This can be seen in the recent troubles concerning GraphQL patent licensing and the disputes that have arisen – a simple change of license format and the resultant understanding (and in some cases, misunderstanding) in the community has sent shockwaves through the API landscape.

Today, we’re going to talk about some purported issues related to the GraphQL patent release to provide context and a bit of clarity. We’ll take a look at whether or not the GraphQL license issue is as significant as first thought, and more to the point, what the newly released patent scheme from GraphQL actually means for most providers.

Background on GraphQL

For those who don’t know what GraphQL is, it can broadly be summarized as an application layer query language. GraphQL interprets strings from the client, and returns data in an understandable, predictable, pre-defined manner. This is a very short, summarized explanation of what GraphQL does, but there is so much more that makes it special – for a more complete summary, check out our piece on the potential benefits of GraphQL adoption.

What is more important to this discussion is how GraphQL was created. After internal development began in 2012 at Facebook, GraphQL was released publicly in 2015, offering an alternative to the dominant architectures of the API space, notably REST.

GraphQL was initially developed to help Facebook cope with challenges in fetching specific data from their collection of services without introducing bloat and complexity. By allowing the client to define the expected data format, Facebook, through GraphQL, was able to design a methodology to deliver data in a more usable, efficient manner.

This usability and efficiency was very attractive to many early adopters. Companies like Pinterest, GitHub, and Shopify quickly began to use GraphQL either wholesale or in part. During the rush to adopt GraphQL, however, there were looming, unresolved questions arising from GraphQL’s creation. There was no licensing language in the public release, or information on whether or not the language was patented, and whether or not legal ramifications were possible. Many questions were left unanswered.

Developers Express Concern

In September of 2017, GitLab officially froze their GraphQL project due to these concerns. In a GitLab issues post, senior director of legal affairs Jamie Hurewitz stated that the BSD+Patents license, which Facebook had adopted to try and alleviate patent concerns, was concerning.

“If we were to allow this license, it could lead to potential future conflicts with software licensed under Apache. Also, we could be impairing the future rights of our customers. Essentially, this is not really an open source product based on the implications of the license. While there is no payment of cash, payment is in the form of giving up future rights.”

The license that had been inserted into the GraphQL release allowed for the use of GraphQL under certain terms that removes your license to use GraphQL under the following terms:

“The [patent] license granted … will terminate … if you … initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook … (ii) against any party if such Patent Assertion arises … from any software… of Facebook … or (iii) against any party relating to the Software.”

In other words, developers were free to use GraphQL, as long as they never challenged Facebook over patent infringement from anything built upon their system by Facebook. Unresolved issues caused outrage among programmers. It was very significant for the community of GraphQL adoptees, and led to many developers pulling away from Facebook and its new patent.

Developer and attorney Dennis Walsh subsequently discussed this issue in a lengthy analysis on Medium, wherein he posited that “Whether Facebook wants to assert these patents is the province of gut feelings and lore. I don’t believe that Facebook ever offensively litigated a patent, but the potential for litigation is more than theoretical — it’s very real if they choose that path.” It was clear that for developers like Walsh, the idea that you had a license to GraphQL as long as you didn’t try to patent or protect your own processes and developments was troublesome.

On August 30th, the co-inventor of GraphQL at Facebook, Lee Byron, addressed concerns on GitHub, and stated that he was “aware” of the patent problem, and that it was currently being worked on. He stated:

“I’ll bring this to the attention of our legal council for their suggestion on how to resolve this issue. We definitely want to ensure the community has all necessary rights to be able to use GraphQL! I’ll make sure we get a speedy resolution.”

Finally, on September 26th, 2017, Facebook relicensed GraphQL under an OWFa 1.0 license, granting a perpetual license to users of GraphQL. While this definitely improves the situation, easing many of the developer issues surrounding the issue, there may still be some cause for concern.

Out of the Frying Pan…

There’s still some cause for concern around the new licensing scheme, however. Facebook has broadly adopted the MIT license, which doesn’t expressly include a patent grant. There was some concern expressed, such as that of RedMonk founder Stephen O’Grady, that adopting MIT over the Apache license, which gave a more clear patent situation to developers, created new concerns:

“The problem is that by choosing this approach, Facebook does not convey with the MIT license any patent grants as they would have under the Apache. If Facebook has patents that read on React, in other words, users of that software are not given an explicit license to them via MIT, only an untested implicit license.”

To O’Grady, this essentially means that Facebook has resolved one patent issue by introducing a second.

Many of these issues are ones that must be tested to be confirmed – in other words, until a patent infringement suit is drawn against or by Facebook, most of the concerns are simply conjecture. Even so, the fact remains that this continues to be, for some, a concerning development. This is certainly an artifact of the API development world as a whole, and is something that will have to be tested, vetted, deprecated, and rebuilt as time goes on.

Patents in the United States were originally envisioned during a time where reproduction could take months at great expense to the creator. Patents were put in place to “promote the progress of science and useful arts” according to its Constitutional call. At the time, the idea of rapidly developing upon an open source standard and forking these projects into additional sub-developments was simply impossible to imagine, and as such, applying patents to the modern web world is resulting in some significant complexity.

Are GraphQL Legal Concerns Blown Out of Proportion?

That being said, there are just as many pundits suggesting that the issue has largely been blown out of proportion. The termination of a patent due to legal proceedings is common in some spaces, and in fact has been practiced by policies applied to such juggernauts as the WebM codec from Google. Such patent terminations, termed “defensive termination provisions”, are largely common in enterprise implementations, and in many cases, their full teeth have yet to be significantly bared in a legal proceeding.

It should also be noted that the defensive termination provision as noted in Facebook’s GraphQL documentation was not nearly as extreme as some others. The Mozilla Public License, for instance, not only strips your patent license in response to legal challenges, but your copyright license as well – without the copyright license, though you may lose the patent license, you could still in theory continue to use the code. With a copyright termination, however, you would be legally obligated to stop using your derivative code entirely.

That is obviously a much more extreme type of license termination, but the issue remains at the forefront of many people’s discussions when adopting GraphQL.

Oil and Water

While some have tried to connect some sort of nefarious purpose to the patent issues at hand, the truth is that what we’re witnessing is a collision of open source ethos with corporate reality. Facebook is a corporation, and as such, it’s to be expected that they would do everything they can to look after their best interest. This is an unfortunate fact of the corporate world, especially for a publicly traded company.

On the other hand, we have open-source philosophy; the idea that code should be shared, developed upon, refined, and extended, with minimal if any protections applied to the foundational code base. While this is, in theory, benefits everyone – resulting in increase security, more refined code, and wider adoption – the fact is that a corporation like Facebook would likely find this sort of approach dangerous considering how many of their core functions are driven by the codebase that is being patented.

Perhaps the most clear reason for much of this concern is the fact that intent can’t really be communicated in patent legalese – whether or not Facebook would use such a patent agreement as a means to attack developers is an entirely different conversation from whether or not the actual patent license as it currently is would be acceptable to most developers. Unfortunately, the two topics are being conflated, leading to the issue at hand.

Final Thoughts on GraphQL Legal Issues

So what does this all mean for the API space? It’s easy to assign nefarious intent to Facebook, but the reality is that Facebook is a public company – as many companies in the API community now are. This means that they have certain concerns that they need to address, and certain expectations concerning the use of their applications and codebase.

That being said, stifling open source implementations is a significant issue – and while that’s not what’s happening in this case, the reactions of some providers to the relicensing (such as dropping GraphQL in fear of possible legal issues) is understandable. That should be the takeaway to all of this – while there are concerns about patent licenses within the GraphQL license language, much of the fear is based on conjecture, and if the possibility of future concern is significant enough to worry an organization, they should consider moving away from GraphQL and into a more open-source friendly, freely licensed alternative.

If you do not intend on creating something that is monetized, or the new re-licensing scheme proposed is an acceptable mitigation, then by all means, continue to use GraphQL. If you still fear the possible issues in the future, ensure that your API can behave for a time without GraphQL or any GraphQL-derived functionality. For those somewhere on the fence, do keep in mind that until there is court action taken, these fears all conjecture.