3 ms·

I was excited to see graphql-engine, but unfortunately the AGPL is a bit hard to pitch to folks in an enterprise software context.

tango12 8y ago
Hey, I'm from Hasura. Out of curiosity, did you face trouble trying to get something like Mongo running in the same enterprise context? Especially back when they were AGPL? We've put up an explanation reg. our AGPL licens here: https://github.com/hasura/graphql-engine/wiki/License-Explained https://github.com/hasura/graphql-engine/wiki/License-Explai...
- yodon 8y ago
  AGPL is pretty much a non-starter for us. It's simply viewed as too risky a license. Thanks to jacues_chester for pointing out the license. The project sounds super cool but there is simply no point in my looking into it on account of that licensing decision. You're shaking my confidence in your decision making, Hasura.
  - quietbritishjim 8y ago
    (I am not from Hasura.) AGPL only makes a difference if you link that program and your own code together into one executable (including through dynamic linking). If you're calling from another executable over an API then it makes no practical difference whether it's AGPL, regular GPL or even BSD-style. This is, by definition, a remote API so you'd really have to make an effort to infect your code with the licence. Just saying "it's too risky" sounds like ignorance. Like if I refused to compile my code with GCC because I heard GCC has a GPL licence. There's not much that vendors can do to counter an attitude like that.
    - JeremyBanks 8y ago
      Many, many companies have blanket bans on AGPL software because they'd rather not take on the risk of accidentally violating it. It might be silly, but it's true.
    - ensignavenger 8y ago
      Are you a lawyer? A great deal many lawyers have reviewed the AGPL and labeled it too risky for their companies. While I tend to agree with your interpretation of it, I still am extra cautious and avoid AGPL software when I can for infrastructure products like this. I am cautious because of the lawyers opinions on it, and I am also cautious because many companies that adopt an AGPL license turn out to be not very good open source stewards, and they put up roadblocks to community contributions that weaken the project and make having a real open source community behind the projects nearly impossible. There are some exceptions, but they are rare, so I exercise extreme caution around AGPL licensed products.
    - noghostartifact 8y ago
      Things like this, https://www.ghostscript.com/faq.html https://www.ghostscript.com/faq.html in the 'Can I embed Ghostscript in my own apps?' section: "The AGPL explicitly prohibits the deployment of AGPL software in a SaaS (Software as a Service) environment unless all of the software on the server (including the operating system software) is also released under the AGPL with full source code." BS like this confuses the otherwise very clear language of the license itself. Removing the arms-length uses of GS from our SaaS because nobody wants any possible legal problems.
  - tyingq 8y ago
    That last sentence took things from constructive/informative to not helpful.
- jacques_chester 8y ago
  I was interested in whether it could be used in Concourse, which is Apache 2 licensed. I wanted a better way to extract data without adding lots of new endpoints. AGPL just doesn't work for anyone downstream who has to answer to enterprise customers. Pivotal, where I work, is the main sponsor for Concourse and so finds itself in that position.
thanatropism 8y ago
I thought the AGPL was corporate-friendly, RMS-unfriendly. Doesn't it allow for the "nonfree" distribution in SaaS/API context? (Am I allowed to describe an API business as SaaS? My [technical, without a business background] partner says no.)
- nothrabannosir 8y ago
  That's the GPL, which only concerns itself with the distribution of (derivative) works. If you modify GPL'ed software for your own use, without distributing it, you can keep your modifications for yourself. SaaS companies were (ab)using that bug by using GPL'ed software in their stack, but never distributing the code: they just rent out use of their machines to others. Therefore they don't need to distribute their own source code.* The AGPL fixes that "bug" by including the SaaS "software on demand" in the definition of "distribution". That's my understanding, as a layman AGPL fan. :) *Where relevant. There are many scary stories about the overreach of the (A)GPL, but it's not always that bad. E.g. if you just use an AGPL'ed database, not embedded or linked but really like a DB with a separate connection, then your code is not under AGPL. Again, from my understanding as a layman.
  - thanatropism 8y ago
    I had the names mixed up. Sorry for the insistence, but is an API-only product still SaaS as far as the Affero license goes?
    - nothrabannosir 8y ago
      Certainly. To understand the GPL family, here's a rule of thumb: they try to ensure to freedom of the software user, not the software developer. The GPL restricts the freedom to restrict freedom. It goes out of its way to ensure users retain their freedom when using software, including the freedom to see the source code and modify it. In interviews, RMS often talks about his frustrations as a software user. From this point of view, the GPL makes more sense. This is also why the GPL is constantly being updated to fix "bugs" which publishers exploit, to circumvent it (TiVoization, SaaS, something else will surely follow). MIT/BSD, on the other hand, are about developers. They let me, as a developer, do what I want, including restrict my users. This is why they're popular among... developers! :) But if you look at it as a user, it's actually not ideal. This is a gross oversimplification, but I find it helps put things in perspective. YMMV!
nothrabannosir 8y ago
Just for clarity: they offer a commercial license, for money. If you work for a company that doesn't like AGPL, perhaps they're more comfortable with paying money for software? Those two tend to go hand in hand, in my experience. https://github.com/hasura/graphql-engine/wiki/License-Explained https://github.com/hasura/graphql-engine/wiki/License-Explai... (The wording is odd, but I parse that as "Commercial licenses ... are available on request.") EDIT: I have to say, the entitled attitude I'm seeing in this thread towards free software, irks me. It's literally dual licensed. Perhaps if your company is so petrified of contributing back to the community (perish the thought), you could bring yourself to pay money? Closed source software never gets this crap, but woe you if you dare offer your code under the same license family that brought us GCC and Linux! Give me a break. Pay money or accept the AGPL, but please don't bully people who offer the fruits of their labour to the open source community under the most freedom license. Sorry for the negativity. And many thanks to Hasura.
- jacques_chester 8y ago
  > EDIT: I have to say, the entitled attitude I'm seeing in this thread towards free software, irks me. It's literally dual licensed. Perhaps if your company is so petrified of contributing back to the community (perish the thought), you could bring yourself to pay money? Well, I like to look at it a different way. The best way for me to comply with the wishes of AGPL licensors is to avoid their code. I am never going to break their terms if I never use their software. I do not intend this in a points-scoring way. I mean it: I am trying to respect their wishes. Now, if I was the end consumer for graphql-engine, and if it gave me a strong commercial advantage to do so, I think it's fine for Hasura to ask me to choose between the AGPL or a private license. I would probably consider the commercial license because I expect it would come with add-ons, support, influence over the roadmap and so on. But my use case is to bundle it as a dependency, meaning it would affect people downstream of me. That I can't do.

tango12 8y ago

Hey, I'm from Hasura. Out of curiosity, did you face trouble trying to get something like Mongo running in the same enterprise context? Especially back when they were AGPL? We've put up an explanation reg. our AGPL licens here: https://github.com/hasura/graphql-engine/wiki/License-Explained https://github.com/hasura/graphql-engine/wiki/License-Explai...

yodon 8y ago
AGPL is pretty much a non-starter for us. It's simply viewed as too risky a license. Thanks to jacues_chester for pointing out the license. The project sounds super cool but there is simply no point in my looking into it on account of that licensing decision. You're shaking my confidence in your decision making, Hasura.
- quietbritishjim 8y ago
  (I am not from Hasura.) AGPL only makes a difference if you link that program and your own code together into one executable (including through dynamic linking). If you're calling from another executable over an API then it makes no practical difference whether it's AGPL, regular GPL or even BSD-style. This is, by definition, a remote API so you'd really have to make an effort to infect your code with the licence. Just saying "it's too risky" sounds like ignorance. Like if I refused to compile my code with GCC because I heard GCC has a GPL licence. There's not much that vendors can do to counter an attitude like that.
  - JeremyBanks 8y ago
    Many, many companies have blanket bans on AGPL software because they'd rather not take on the risk of accidentally violating it. It might be silly, but it's true.
  - ensignavenger 8y ago
    Are you a lawyer? A great deal many lawyers have reviewed the AGPL and labeled it too risky for their companies. While I tend to agree with your interpretation of it, I still am extra cautious and avoid AGPL software when I can for infrastructure products like this. I am cautious because of the lawyers opinions on it, and I am also cautious because many companies that adopt an AGPL license turn out to be not very good open source stewards, and they put up roadblocks to community contributions that weaken the project and make having a real open source community behind the projects nearly impossible. There are some exceptions, but they are rare, so I exercise extreme caution around AGPL licensed products.
  - noghostartifact 8y ago
    Things like this, https://www.ghostscript.com/faq.html https://www.ghostscript.com/faq.html in the 'Can I embed Ghostscript in my own apps?' section: "The AGPL explicitly prohibits the deployment of AGPL software in a SaaS (Software as a Service) environment unless all of the software on the server (including the operating system software) is also released under the AGPL with full source code." BS like this confuses the otherwise very clear language of the license itself. Removing the arms-length uses of GS from our SaaS because nobody wants any possible legal problems.
- tyingq 8y ago
  That last sentence took things from constructive/informative to not helpful.
jacques_chester 8y ago
I was interested in whether it could be used in Concourse, which is Apache 2 licensed. I wanted a better way to extract data without adding lots of new endpoints. AGPL just doesn't work for anyone downstream who has to answer to enterprise customers. Pivotal, where I work, is the main sponsor for Concourse and so finds itself in that position.

thanatropism 8y ago

I thought the AGPL was corporate-friendly, RMS-unfriendly. Doesn't it allow for the "nonfree" distribution in SaaS/API context? (Am I allowed to describe an API business as SaaS? My [technical, without a business background] partner says no.)

nothrabannosir 8y ago
That's the GPL, which only concerns itself with the distribution of (derivative) works. If you modify GPL'ed software for your own use, without distributing it, you can keep your modifications for yourself. SaaS companies were (ab)using that bug by using GPL'ed software in their stack, but never distributing the code: they just rent out use of their machines to others. Therefore they don't need to distribute their own source code.* The AGPL fixes that "bug" by including the SaaS "software on demand" in the definition of "distribution". That's my understanding, as a layman AGPL fan. :) *Where relevant. There are many scary stories about the overreach of the (A)GPL, but it's not always that bad. E.g. if you just use an AGPL'ed database, not embedded or linked but really like a DB with a separate connection, then your code is not under AGPL. Again, from my understanding as a layman.
- thanatropism 8y ago
  I had the names mixed up. Sorry for the insistence, but is an API-only product still SaaS as far as the Affero license goes?
  - nothrabannosir 8y ago
    Certainly. To understand the GPL family, here's a rule of thumb: they try to ensure to freedom of the software user, not the software developer. The GPL restricts the freedom to restrict freedom. It goes out of its way to ensure users retain their freedom when using software, including the freedom to see the source code and modify it. In interviews, RMS often talks about his frustrations as a software user. From this point of view, the GPL makes more sense. This is also why the GPL is constantly being updated to fix "bugs" which publishers exploit, to circumvent it (TiVoization, SaaS, something else will surely follow). MIT/BSD, on the other hand, are about developers. They let me, as a developer, do what I want, including restrict my users. This is why they're popular among... developers! :) But if you look at it as a user, it's actually not ideal. This is a gross oversimplification, but I find it helps put things in perspective. YMMV!

nothrabannosir 8y ago

Just for clarity: they offer a commercial license, for money. If you work for a company that doesn't like AGPL, perhaps they're more comfortable with paying money for software? Those two tend to go hand in hand, in my experience. https://github.com/hasura/graphql-engine/wiki/License-Explained https://github.com/hasura/graphql-engine/wiki/License-Explai... (The wording is odd, but I parse that as "Commercial licenses ... are available on request.") EDIT: I have to say, the entitled attitude I'm seeing in this thread towards free software, irks me. It's literally dual licensed. Perhaps if your company is so petrified of contributing back to the community (perish the thought), you could bring yourself to pay money? Closed source software never gets this crap, but woe you if you dare offer your code under the same license family that brought us GCC and Linux! Give me a break. Pay money or accept the AGPL, but please don't bully people who offer the fruits of their labour to the open source community under the most freedom license. Sorry for the negativity. And many thanks to Hasura.

jacques_chester 8y ago
> EDIT: I have to say, the entitled attitude I'm seeing in this thread towards free software, irks me. It's literally dual licensed. Perhaps if your company is so petrified of contributing back to the community (perish the thought), you could bring yourself to pay money? Well, I like to look at it a different way. The best way for me to comply with the wishes of AGPL licensors is to avoid their code. I am never going to break their terms if I never use their software. I do not intend this in a points-scoring way. I mean it: I am trying to respect their wishes. Now, if I was the end consumer for graphql-engine, and if it gave me a strong commercial advantage to do so, I think it's fine for Hasura to ask me to choose between the AGPL or a private license. I would probably consider the commercial license because I expect it would come with add-ons, support, influence over the roadmap and so on. But my use case is to bundle it as a dependency, meaning it would affect people downstream of me. That I can't do.