Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GraphQL Patent Infringement Issues #351

Closed
LawJolla opened this issue Aug 29, 2017 · 49 comments · Fixed by #368
Closed

GraphQL Patent Infringement Issues #351

LawJolla opened this issue Aug 29, 2017 · 49 comments · Fixed by #368

Comments

@LawJolla
Copy link

Hi Guys,

First, thank you for your incredibly hard work and brilliant design. You've helped me and many others.

I believe that there's an IP issue over GraphQL that needs to be brought to Facebook's attention. GraphQL patents are issuing and there are no patent grants in the specification. I read these patents to cover core functionality and difficult (thought not impossible) to design around. However, the current spec leads most implementations to be infringers.

For more, here are my full thoughts.

https://medium.com/@dwalsh.sdlr/using-graphql-why-facebook-now-owns-you-3182751028c9

I've been a Facebook licensing defender for other OSS like React, but I think this is a completely different issue and hope this can start a dialogue up the chain.

Thank you!

@SEAPUNK
Copy link

SEAPUNK commented Aug 29, 2017

🍿

@leebyron
Copy link
Collaborator

leebyron commented Aug 30, 2017

Hi @LawJolla, thanks for highlighting this and for the well researched blog post.

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.

@smolinari
Copy link

smolinari commented Aug 30, 2017

@leebyron - in general the patent appendage to FB's BSD + patent license is at best, just a paper tiger, as @LawJolla contests. Or at worst, it is a poor message, like FB is just another large enterprise that only thinks about its greedy self. I'm paraphrasing the overall perspective of comments I've read, when I say that.

I guess the question is, is the value of the protection expected from the added patent conditions higher than the negativity and uncertainty it causes. I'd think not and it is not really true to OSS community values, if FB were honest about it.

Scott

@leebyron
Copy link
Collaborator

Hi @smolinari, I understand this is a contentious issue and that the legal portion of open source can be frustrating since decisions they are not always in the hands of the engineers building the software, and their implications are not always clearly understood.

I'm discussing this issue with our legal council and will try to find a solution that provides the necessary legal rights for the community to continue to use and contribute to GraphQL. I'll share updates as soon as I can.

@yordis
Copy link

yordis commented Aug 30, 2017

@leebyron sorry if I ask something that is already answer but between English and my ignorance I am really lost.

Does the Patent affects the Specification itself?

I am kind of fine if you put some patent on the implementation of such of specification, but I wouldn't expect to be affected even using the specification.

I can't even imagine that

@LawJolla
Copy link
Author

LawJolla commented Aug 31, 2017

@leebyron thanks for your help and quick attention!

As someone who's patented many inventions for large companies, I know how the machinery works. Facebook counsel farms the IP to an external firm that handles the application independently. Then three years later, FB decides that open source a the better route, but the outside firm continues to chew the application.

But GraphQL is a different open source monster from other FB projects because it's a spec (without a patent grant) and not software.

And thank you again for your hard work and advocacy! Your time and brilliance greatly benefits my life and makes my business goals possible.

@smolinari
Copy link

smolinari commented Sep 1, 2017

I just ran into this article.

https://medium.com/@reverdev/why-we-moved-from-angular-2-to-vue-js-and-why-we-didnt-choose-react-ef807d9f4163

Notice the part about FB's license and how it helped sway the decision away from React.

and this note in the comments:

and the licensing on React is just ridiculous, but we’ve known about that for more than a year; we’re just paying attention, now

I ask again, is the expected protection of the BSD + patent license worth such negative vibes, which seem to be getting worse? Is FB's OSS really the place to leverage the fight against patent trolling (if that is the intended purpose)?

Scott

@ghost
Copy link

ghost commented Sep 7, 2017

It would be helpful to link to the patent related to this: https://www.google.com/patents/US9646028

It looks like that patent covers GraphQL, how does this affect companies who are relying on GraphQL is the big question here. Perhaps this is why the reference implementation for JavaScript includes the PATENTS grant: https://github.com/graphql/graphql-js/blob/master/PATENTS

My personal opinion is we should #EndSoftwarePatents very disappointed that anyone would put their name on that patent filing especially when patents do not encourage innovation at all.

@leebyron
Copy link
Collaborator

leebyron commented Sep 7, 2017

These days I share your opinion @omouse that software patents are typically negative. They're very often too broad and don't match the pace of the industry. Unfortunately, at least here in the US, they're the law of the land and there's massive costs to those involved.

I'll refer you to a blog post from our team's director related to this topic: https://code.facebook.com/posts/112130496157735/explaining-react-s-license/

@ghost
Copy link

ghost commented Sep 7, 2017

@leebyron thank you for the reply and the link to that blog post!

@yordis
Copy link

yordis commented Sep 7, 2017

@leebyron I could understand any Patent/Law against any law sue because of the usage or any spec , lib and frameworks made by Facebook but I can't not understand anything add it outside that, specially on open source projects.

@idibidiart
Copy link

There is a lot of fuss about FB OSS patents and the way they're granted but the whole issue is moot until and unless those patents hold up in court, which knowing the prior art for both GraphQL and Reacf I heavily doubt they they could. so if company A uses GQL and sues FB then FB sues back and tries to force them to not use GQL I think we will have a laugh then. Can't see how it would work. Seems better off for FB to change the license to remove that non-sense.

A fan and advocate for both GQL and React, and FB OSS in general.

@idibidiart
Copy link

I realize the issue being raised is about infringing for simply developing a GQL server. Same comment applies here: moot until GQL patent is proven valid in a legal case. Till then it's pure legal posturing.

@syrusakbary
Copy link

syrusakbary commented Sep 8, 2017

As @LawJolla commented, I think there is a big difference between React and GraphQL, specially regarding patents. While one is a framework, the other is a specification.

So we can't really look at both with the same eyes, neither accept the React license explanation in the GraphQL topic.

Focusing on GraphQL, here are some of my worries, whose answers might help to understand what are the real implications of the Patent:

  • How this affects the different frameworks and ecosystems?
    • GraphQL server implementations (both open-source and closed-source, SaaS, ...).
    • GraphQL server tooling
    • GraphQL clients (it seems this case will be the less vulnerable to the Patent, as analyzed by the article)
  • How this affects to new specifications highly inspired by the GraphQL spec? (Let's say GraphQL+) Could Facebook demand them?

Compared to GraphQL, SQL it's been a specification/standard that's been around for some years now and have zero patents associated to the standard itself. So, should we accept the Patent argument for the GraphQL case?

Perhaps including a patent grant in the GraphQL spec will help to alleviate this concerns.

@dosire
Copy link

dosire commented Sep 19, 2017

We're grateful for GraphQL and believe it is the future of inter application API's (with GRPC being the future of intra application API's). I wanted to mention that at GitLab we decided to put our GraphQL implementation on hold, in https://gitlab.com/gitlab-org/gitlab-ce/issues/34754#note_40144735 our Senior Director of Legal Affairs mentions: "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."

@LawJolla
Copy link
Author

LawJolla commented Sep 19, 2017

@syrusakbary dead on and well said.

The longer that this drags out, the more I wonder what's going on. I have faith in Facebook and still do. But the answer is obvious, and the fact we're so far into this without any legal uttering is disturbing.

Software patents are rarely commercially valuable because most claim arbitrary elements. That is, if you were independently designing a similar system, odds are high your implementation, just by sheer implementation chance, would zig instead of zag. That zag would miss the claimed, patented arbitrary implementation.

But a way to make sure your arbitrary implementations are followed is to create an open spec. Then the arbitrary claimed elements (and GraphQLs patents have a few) are followed and infringed. Was GraphQL open sourced as a tech poisoned pill? I don't think so. But as previously expressed, this delay is worrisome.

Since Facebook legal may read this post, I think the developer community is in enough of an uproar to mount a crowdsourced / crowdfunded USPTO request for reexamination of Facebook's patents to invalidate them.

@emrul
Copy link

emrul commented Sep 20, 2017

I think the real issue here is that the patent is patentable at all! Reading the linked article says the examiner requested they limit to social networks but that sounds non-intuitive - what kind of social network isn't based on a graph?

And querying graphs is not 'new' or 'innovative' - I've worked with XML databases many years ago where you could issue XPath-style requests over a network connection and they would traverse and return results. GraphQL is hardly different from that - it's just a nicer application of it since we now live in a mostly XPath/XSLT/XML-free world.

@leebyron
Copy link
Collaborator

leebyron commented Sep 20, 2017

Hey all, thanks for your continued attention, care, and patience on this issue.

I wanted to share an update that this is still something I'm working hard on resolving. While it's become more clear to me what the spectrum of acceptable to ideal looks like from the perspective of the broader community, reconciling all other interests is a challenge and takes some time. Also, working on licensing for a specification instead of an open source codebase is somewhat new territory, which is causing this to take some additional time.

@SuryaSankar
Copy link

SuryaSankar commented Sep 20, 2017

Since the language of the patent is too broad, does it mean that anyone implementing any such hierarchical querying system is violating this patent? Such query languages have been around for a long time before GraphQL came into the picture. Netflix’s Falcor comes to mind.

How will such query languages be affected by this patent? Will someone be liable to get sued for building and distributing another hierarchical query language system, which was implemented independently of GraphQL ? And will the users of that system also become liable?

If so, that is really bad and it won't be solved by just including a license grant along with GraphQL. If I am liable to get sued because I am building/using a completely independent hierarchical querying system - that sounds very unfair.

Please clarify this point as well.

@bsbechtel
Copy link

bsbechtel commented Sep 20, 2017

Based on my reading of the patent and the comments in the Medium article by @LawJolla, I don't see the GraphQL patent passing the obvious test.

The question would be whether or not a social-network system is an obvious limitation to someone skilled in the art. Given the volume of prior art filed with the USPTO using that terminology, it seems hard to believe any arguments claiming non-obviousness are credible.

A method of organizing and communicating abstract information, which the Examiner stated the patent amounted to before adding the social-networking system limitation in the claim, still fails to qualify for a patent if an obvious limitation is applied to the claim. I agree with @emrul on this.

Edit: To put it another way, to invalidate the patent, you just need to prove someone queried data over a graph before Facebook filed, and that data was part of a social-network system.

@cloutiertyler
Copy link

@bsbechtel When was the filing date? I did this back in 2015: https://github.com/cloutiertyler/RibbonGraph. It's a similar concept but with a declarative permissions system.

@ghost
Copy link

ghost commented Sep 20, 2017

since a few people mentioned prior art, there's also the SPARQL specification from 2008 and finalized in 2013, you can see an example in the Wikidata Query Service, here's an example query to try:

SELECT ?computer ?computerLabel ?location ?locationLabel WHERE {
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  
  OPTIONAL {  }
  ?computer wdt:P31 wd:Q68.
  OPTIONAL { ?computer wdt:P495 ?location. }
}
LIMIT 100

May not look like GraphQL but it is using one schema to query multiple other schemas which is basically what GraphQL is for.

cc @LawJolla

@yordis
Copy link

yordis commented Sep 20, 2017

I can't believe we are talking about patenting an specification like this one, I refused to even think about it.

With all the respect to all the engineering department of Facebook, but I would crash the legal department for this, my ethic as an engineer worth more than whatever Facebook could pay me.

How it's possible to accept this, I would prefer Facebook to be like Microsoft 1990 and close source everything, it's way better than put this out there open source and many of us that have no clue about legal details go to the hell because of this practices from Facebook.

I know that is not 100% the engineering department of Facebook faults but if you can't win this battle who will?!, either you really work harder on this or the whole industry will becomes this nightmare, I bet a lot of companies will start copying this practices and there is no going back.

@yordis
Copy link

yordis commented Sep 20, 2017

@omouse pretty much, just put some JSON at front and it's the same. So basically patent JSON structures?! This doesn't even makes sense.

I wouldn't care about the implementation on NodeJS and those code, but patent in this specification, really!?

@idibidiart
Copy link

Last time I commented I stated that the discussion is moot until the patent is tested in court and given the prior art no one should assume that the patent is valid. I was wrong. People are worried about the lawsuit and cost of fighting it, not about whether they'd prevail or not.

Here is some of the better known prior art:

https://www.slideshare.net/mobile/SumitSarkar10/rest-api-debate-odata-vs-graphql-vs-ords

@bsbechtel
Copy link

bsbechtel commented Sep 20, 2017

@idibidiart I understand the concern, but I think both discussions are worth having, and also closely related. It only takes one case to invalidate the patent, unlike a copyrighting license. Yes, the legal fight would be expensive and time consuming for that individual team, but it would also be a case where a win for that team would be a win for the entire open source community. Hopefully the community would realize this, and find various ways to express their support.

I should mention that, at the end of the day, a solution that works for Facebook, the open source community, and the US Patent System is the optimal outcome, whatever that solution may be.

@idibidiart
Copy link

@bsbechtel @yordis

Agree on all points. This is a serious issue.

I know @leebyron is a serious guy and is 1000% behind open source and doing the right thing. He's a pillar in the community.

I also know corporate legal departments are full of people trying to justify their existence.

It would not be fun for those at FB Legal if this lack of foresight cost them a useless legal battle with other patent holders whose patents are infringed upon by the FB patent. Just because one company has a patent on something it does not mean that it doesn't infringe on other patents.

Reference:
https://www.google.com/search?q=can+a+patent+infringe+another+patent&rlz=1C5CHFA_enUS734US734&oq=can+a+patent+infringe+&aqs=chrome.0.0j69i57j0l3.5200j0j9&sourceid=chrome&ie=UTF-8

There is a potential material risk to FB themselves from their patents coming under scrutiny.

Normally, companies acquire patents to use in bargaining in case of lawsuits and not in preemptive fashion as FB has done.

There is definitely a risk to FB here.

If they're smart, they'll put a lid on this whole thing, undo the stupid license, and regain trust of the OSS community, before things get out of control for them and the companies who have invested in GraphQL.

@yordis
Copy link

yordis commented Sep 20, 2017

@idibidiart I hope they don't because they I screwed badly my own company, all my businesses are running on top of GraphQL endpoints so

@SuryaSankar
Copy link

SuryaSankar commented Sep 20, 2017

FWIW, I have built and used a library which implements hierarchical querying abilities on top of a REST API built using Flask and SQLAlchemy. Have been working on it since late 2014 - https://github.com/inkmonk/flask-sqlalchemy-booster

It would allow you to declaratively build API endpoints which can be queried like
/resources/(id)?_ds={'f':{'id': {'op': '>', 'v': 5} }, 'attrs': ['id', 'name'], 'rels':{'rel1':{'attrs':['id','date']}}} etc.
But I am not sure if small projects like mine can prove that they were in prior use before GraphQL came into picture. In my case I am the sole user of my library.

But surely, libraries like Falcor and specifications like SPARQL pointed out above - should be able to make an use case for prior art. It is sad that this is even being debated. I would like to think of this as something as abstract as REST itself - and hence should be out of bounds for any patent application.

@idibidiart
Copy link

idibidiart commented Sep 20, 2017

A specification in this context is an API, right? The graphQL query/mutation and schema spec is the API for GraphQL. If that's incorrect, please explain how else it would need to be framed.

If it is correct, the Google vs Oracle Android battle proved that you cannot patent an API.

https://www.publicknowledge.org/news-blog/blogs/why-you-cant-copyright-an-api

It’s a basic fact of copyright law that you can’t copyright methods or procedures for doing things.
 You might be able to copyright particular expressions for things—like an evocative description of 
how to combine and prepare ingredients in a recipe—but you can’t copyright the basic facts behind 
it—the ingredients, their amounts, and the order in which you combine them.

The same is true of blank accounting forms, the rules of games, or any other situation where you 
need a set of structures in order to interface with an underlying system. What you’re doing is 
creating a set of ideas of how to interact with a system, and ideas in themselves aren’t 
copyrightable. You might copyright the book on accounting that contains your blank forms and 
explains them; you might copyright the booklet that contains your particular description of the rules 
of your new board game. But the underlying ideas that those things describe—the forms and the 
rules—can be used by others without your permission.

The same thing should be true for APIs. An API, or “application programming interface,” is a 
framework used to communicate with a given computer system. If I want an application to perform a 
particular calculation on a couple of variables and send me the result, I need a way to structure that 
request. Just as with the rules of the game, the particular name of that request, and the order in 
which it takes its inputs, and how it spits back its result, are all parts of a process and method—an 
idea. But a case decided by the Federal Circuit this past May threw that into confusion.

@eapache
Copy link
Member

eapache commented Sep 20, 2017

the Google vs Oracle Android battle proved that you cannot patent an API.

Patents and copyrights are entirely different things with very different rules, and anyway the Federal Circuit upheld Oracle's copyright claim in that case.


As a more general note for this thread: it's pretty obvious that Lee is aware of the concerns, and working with the Facebook legal team to come to a solution. I look forward to putting this to rest.

In the meantime, there's not a lot that anybody can do, and speculating about complicated legal topics is resulting in a lot of misinformation and confusion here. If you're not a lawyer practicing American IP law (i.e. @LawJolla) please kindly stop.

@leebyron you may want to consider locking this thread until Facebook legal has something concrete to share.

@idibidiart
Copy link

I thougjt the issue is they patented the specification not merely copyright it?

Locking the thread is a panic driven move. I would do the same if I was FB, but c'mon guys, if you shutdown one avenue for releasing frustration and sharing (mis)information people will find otheravenurs like Hacker News et al amd then it will really get out of hand

@geospofford-anaplan
Copy link

I believe the patent covers software that does the stuff that GraphQL does, such that GraphQL itself is just one embodiment. If you created your own implementation of GraphQL, you'd be infringing. If you created your own implementation of something sufficiently similar, you'd be infringing. You can only copyright a specification.

@idibidiart
Copy link

Right! So if they can't patent the specification but they have patented how GraphQL does stuff then chances are their patent infringes IBM's patents for OData and other patents held by major players in this field. That's just my naive brain can work out. Whether the discussion amongst us developers is generating misinformation or not, the answer is definitely yes, but that's just a byproduct of FB's confusing license. Folks need to focus on the cause not the symptom.

I've sold a $2B consulting firm (3rd largest in US) on GraphQL and I was almost going to have major US retailers adopt it. This won't derail my plans until the plot goes wrong. What I expect is for FB to immediately change the license and sort stuff out.... as opposed to let it linger and affect so many companies and themselves in the process.

In other words, lock the tread or whatever but do take immediate action. This is not a small issue.

Fingers crossed.

@dkrieger
Copy link

Disclaimer: not a lawyer, not affiliated with FB, just a user of FB OSS.

I think FB wants to see this litigated. Some very popular licenses (I'm looking at you GPL) don't seem to be grounded by/in legal precedent. FB wants BSD+ to be legally tested so that OSS licenses carry more legal weight. Many people assumed that the BSD license was tantamount to a patent license that couldn't be selectively revoked based on litigation, and while that is a reasonable assumption IMO, there isn't much in the way of precedent to back it up. FB and other large companies would rather trust the mutually assured destruction of patent trolling than the mutual benevolence of companies using OSS.

OSS licenses exist in parallel to the patent system, and while the intuition of devs (myself included) is that permissions granted by the OSS license overrule restrictions imposed by the patent, the fact that there is far more case law surrounding patent enforcement makes the opposite the likelier scenario, namely that the patent overrides the OSS license.

Typed on my phone, sorry for errors or rambling.

@Merovius
Copy link

As someone subscribed to this issue to keep updated about the issue: Can I second the request to keep speculation (legal and otherwise) to a minimum? There are lots of forums to discuss this or speculate about it (HN, reddit,…). I at least am here waiting for updates from FB and/or actual experts. Speculation doesn't really help and just takes up attention.

@leebyron
Copy link
Collaborator

leebyron commented Sep 21, 2017

Hey everyone, speculation on legal interpretation is really unhelpful in this forum. Let's keep this thread only as a high signal channel for those looking for updates as they arrive.

Resolving this is still my top priority and I'm working to a conclusion with our legal team. I understand patience is hard to ask for when your company's legal counsel may be asking questions or making demands from you, and that open source licenses and patents are frustrating topics to operate around as an engineer.

I expect to have more updates soon, thanks for caring about this issue and granting me a bit of your patience.

@dosire
Copy link

dosire commented Sep 22, 2017

Facebook announced they will relicense React under MIT Expat https://code.facebook.com/posts/300798627056246 Awesome!

@grahamegrieve
Copy link

I encourage FB to consider transferring GraphQL to a formal standards body, or at least laying out a roadmap to doing so

@smolinari
Copy link

smolinari commented Sep 23, 2017

@dosire - That's great. But what about their patent on GraphQL "technologies"?

That's what got this thread started. As I see it, FB either needs to grant a patent license for anyone doing GraphQL and add the patent clause "only" for those suing them due to GraphQL technology patent infringements, or they could drop the GraphQL patent and add a clause that GraphQL technology cannot be patented by anyone else.

If you ask me, a clause avoiding patents is actually missing in the MIT license. Something like, "No patents may be made from this software or its concepts or any derivative software using this software.". That maybe not the proper legal way to formulate it, but you get the drift. OSS needs to fight against software patenting, because they (and those trying to take advantage of them in unethical ways) are the evil in this game. FB is only trying to protect themselves from these people in the end and I can understand that. But, it derails their projects from the OSS community spirit, unfortunately. And as you can see from the React announcement, Facebook gets it, which is totally cool!

Now to solve GraphQL's OSS community and patent issues! 😄

Scott

@andrewbanchich
Copy link

@grahamegrieve @leebyron I completely agree. GraphQL is being hailed by many developers as a replacement for REST. Please allow it to become this and not limit its potential impact with licensing issues. GraphQL needs a formal standards body.

@leebyron
Copy link
Collaborator

leebyron commented Sep 26, 2017

I have an update to share. The GraphQL spec will be relicensed under the Open Web Foundation Agreement v1.0, which has explicit terms concerning patent non-assert and license commitments. I hope this is a satisfactory resolution to the patent licensing issue.

In light of this change and the release of React 16 under MIT, our reference implementation GraphQL.js and client framework Relay will also relicense under MIT. I'll be working on updating those repositories as well. The first PR is already up: graphql/graphql-js#1046

@omarshibli
Copy link

That's great! Thank you Facebook for pushing the web towards open and accessible standards!

@LawJolla
Copy link
Author

LawJolla commented Sep 26, 2017

Incredible work @leebyron . I've read the OWF v1.0 and think it's entirely appropriate for GraphQL and should put the legal issues to bed.

I sent up another Medium post that Facebook needs to go on record stating there are no patents protecting their MIT licensed software.

But as far as GraphQL, let's close this issue and move on to bigger and better things! 🎉 Thank you contributors for enriching my life... and allowing me to never write another forsaken REST endpoint. 😂

leebyron added a commit that referenced this issue Sep 26, 2017
* Add OWFa v1.0 license agreement to GraphQL specification.

Find the full text of the agreement: http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0

Read more about this change at: https://medium.com/@leeb/relicensing-the-graphql-specification-e7d07a52301b

Resolves #351

* Add signed agreement
@leebyron
Copy link
Collaborator

For anyone looking for this change within the spec, note that new changes will appear at http://facebook.github.io/graphql/draft/ once they make their way through the Travis CI gauntlet.

@smolinari
Copy link

Thanks so much @leebyron. This is big from a higher standpoint to me, because it shows that even big corporations can show true heart, community spirit and do what is best for everyone in the end.

Way to go!!!! 👍

Scott

@sminnee
Copy link

sminnee commented Oct 3, 2017

@leebyron this is great news, well done on advocating for this internally.

I have an implementation question that perhaps you can pass back to your legal team: how should we ensure that a 3rd party implementation such as https://github.com/webonyx/graphql-php "links back" to the OWFa-licensed specification to clarify that it is covered by its patent grants.

For example, should there be some kind of reference sentence in the LICENSE of graphql-php? Are you planning on making some relevant reference in graphql-js as a guide?

I understand, of course, that anyone who is particularly nervous about such things should seek their own legal advice, but I thought it would be better to start with a Facebook-recommended model to apply in such situations, rather than every project getting something draft by their own lawyer.

Thanks again for your work on this,
Sam

@sminnee
Copy link

sminnee commented Oct 13, 2017

@leebyron are you able to comment on the above?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.