5

If there's a public API server that has it's source code licensed with AGPL, and if I make an app that uses these public endpoints in some part of it, (entire application doesn't necessarily depend on it but a functionality) is this considered as "derivative work" thus oblige me to license my code with AGPL too? Note that, I'm not manipulating it's source code, merely making RESTful API calls to some server.

I've looked for similar discussions and they claim those are separate programs and the app that consumes the API doesn't have to open its source

But if that's OK, it brings up some follow up questions.

Let's say there's an open source library licensed with AGPL, and if I were to create a thin API wrapper around it, which is also open source and licensed with AGPL, can I make a closed sourced app that does RESTful calls to a server that has this new API deployed, thus effectively bypassing the restrictions of AGPL for the library?

Note that library owners might be commercializing their work by providing a commercial dual license (like iText) to bypass restrictions of AGPL without using nefarious tricks like I described above. So if this is possible, it may create a problem for people that make money from open source projects.

  • 2
    If you are only using an API (and not copying any code), you do not need to consider the license of the underlying code, only that site's terms of service. For all you know, that site offering that API is using some other software or is using it under different licensing conditions. – Brandin Apr 18 at 4:47
  • @Brandin since that's pretty much the answer, why not write it up as one? – MadHatter supports Monica Apr 18 at 9:32
  • @Brandin So is it possible to use an AGPL licensed library in a closed source application if we wrap it with an open source API layer – M.Mücahid Benlioğlu Apr 18 at 14:43
  • @M.MücahidBenlioğlu Note that this problem belongs to a broader category which is not new or AGPL-specific: it's quite similar to, e.g., "Is it possible to use a GPL-licensed library in a closed-source application if we package the lib as a standalone executable and call it as a separate process with exec?" (I won't attempt to answer this question in this comment, but only note the similarity of the questions.) – apsillers Apr 18 at 15:43
  • 2
    What you've described in this question is basically a "front end" to another, lower level program. If you make a nice shiny "front end" in which all you're essentially doing is calling an (A)GPL program, passing its arguments, and returning its results, there's almost no argument possible where you could claim that the front end program is a "derivative work" of the (A)GPL program, especially if the front end and the (A)GPL program are not even distributed together. This would be like saying that an iPhone carrying case is derivative of an iPhone. – Brandin Apr 19 at 11:43
5

Making calls to a public API

If there's a public API server that has it's source code licensed with AGPL, and if I make an app that uses these public endpoints in some part of it, ... is this considered as "derivative work" thus oblige me to license my code with AGPL too?

No. A derivative work is only possible if you've copied at least some part of the original work, or if you've made a new work based on an existing work. E.g. if you wrote a similar program with similar functionality while having access to the original program, then your new program could possibly (but not necessarily) be considered a derivative work.

In the situation you describe (making requests to a server), you are not copying anything that could be considered a portion of the program itself. You are merely running the program.

If that public API server is offering a service to you using (A)GPL code, then that server operator is the one that needs to comply with the software licenses, because she is the one that copied the code onto her server in order to offer the services to you.

Generally speaking, if you are only running a program, and not copying it or making a derivative work from it, no permission is generally required according to copyright laws. The GPL (and thus, the AGPL as well), even go so far as to explicitly affirm that you are indeed allowed to run a GPL-covered program, even if you do not accept the underlying license:

  1. Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive or run a copy of the Program.

https://www.gnu.org/copyleft/gpl.html

Does this allow circumventing the AGPL?

Let's say there's an open source library licensed with AGPL, and if I were to create a thin API wrapper around it, ..., can I make a closed sourced app that does RESTful calls to a server that has this new API deployed, thus effectively bypassing the restrictions of AGPL for the library?

If the AGPL program does not offer a REST API, and you decide to add one to it and then offer that program on a server where users can interact with it, then the AGPL would require that you contribute the source code of your version (i.e. the one with the REST API implemented) to anyone who can access the service through a network.

[If] you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version ...

https://www.gnu.org/licenses/agpl-3.0.en.html

In this sense, you are not circumventing anything. You made changes to the AGPL program, so you must disclose your source to that program.

As for your second program that calls your REST service, the AGPL does not make any requirement on that program for the same reason as mentioned above (calling a REST service is not a form of copying the program).

Does this circumvent the purpose of AGPL? I don't believe so. The purpose of AGPL is to prevent you from circumventing your obligation of contributing your improvements to the program itself. For example, suppose you have an idea for improving the GNU C Compiler (which is GPL licensed), so you download the GCC source and make your improvements. According to the GPL, the mere fact that you've modified GPL code is not enough to require you to release your source code changes. Only if you actually distribute your custom GCC program are you required to release your source code (or a Written Offer to provide the source code). Not wanting to do this, you decide to instead install your custom GCC program onto your own server, and then only let users interact with it over a network. Since GCC is GPL licensed (and not AGPL licensed), this would be OK according to the license, although it would probably be a shame, since the authors of GCC probably intended for you to eventually disclose your source code changes when you finally release your software. It's just that technically you never "released" your software in this case.

The intention of the AGPL is to clarify this sitation -- if you take an AGPL-licensed program, and make changes to it in some way, and then you let users interact with your version over a network, the AGPL says that that bascically counts as releasing your version, so you need to in turn release your source code to your version.

See also: Why the Affero GPL

1

The goal of GPL-style licenses is to ensure end user freedom. For the GPL, anyone who receives a copy of the software also receives the full rights under the GPL. But with network-based software, this no longer works: the end user never receives a copy of the software they are using. The AGPL steps in here: it ensures end user freedom also when the user is only interacting remotely with the software.

How can that restriction legally work if the software is never copied? Copyright doesn't just reserve the right to make copies, it also reserves the right to public performance. Under the AGPL, the copyright holders license the public performance right to whoever runs the software, but under the condition that they also offer the source code to remotely interacting end users.

In your scenario, your wrapper API is not generally a derived work of the API server, and you are not generally bound by the AGPL. However:

  • if you provide both the API server and the wrapper API, you are still bound by the AGPL to offer the source code to remotely interacting end users. A simple proxy probably does not break this interaction.
  • if you are effectively forwarding the public performance of the software by a third party, it could be argue that you are infringing because you have no license for this public performance. That is a creative legal argument though.
  • if your software is not a wrapper but some software that merely uses the AGPL-covered API, no issues arise: the end users of your API are clearly not interacting with the upstream API server. For example, using an AGPL-covered database server is generally unproblematic.

If in doubt, keep “a bright line between the free and proprietary pieces that would be extremely clear to any court” (Bruce Perens). Don't try pulling any tricks that are obviously just attempts at circumvention.

  • In my scenario, I create the wrapper API under AGPL and I also create another, stand-alone, closed source app that uses the API. From my understanding this goes under the third category of your answer, so as you said it's not problematic. – M.Mücahid Benlioğlu Apr 19 at 20:54
  • @M.MücahidBenlioğlu Not quite. I do not understand why anyone would think that introducing an AGPL-licensed wrapper would help: either it is legally useless (and does not shield you from the AGPL), or it is unnecessary. You do probably fall under the latter point where the open-source license of the API has no effect on you. – amon Apr 19 at 21:03
  • Under AGPL I cannot link the library to a closed source app. But I can do RESTful API calls to a server if there's an independent API that wraps the library, deployed there. I don't see how this is useless or has no effect – M.Mücahid Benlioğlu Apr 19 at 23:43
  • I couldn't legally include the AGPL licensed library and use its functions in my closed source code but with the API calls I can use them indirectly. – M.Mücahid Benlioğlu Apr 19 at 23:58
  • 1
    @M.MücahidBenlioğlu OK, now I understand: your wrapper API is not proxying another API, it is exposing a library as a service. In that scenario (where no end users interact with the AGPL-covered software), the AGPL behaves identically to the GPL. This kind of purely internal use is most likely fine, especially if you keep the AGPL-covered parts clearly separate from your proprietary code: avoid the impression that your wrapper were part of your proprietary code. – amon Apr 20 at 8:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.