Frappe Licensing & Software Architecture

Community
1

Hi,

Is there a licensing guide available somewhere for the “Frappeverse” (Frappe Framework + Apps)?

In another topic @rmehta confirmed that the current strategy of Frappe is to release new apps under the AGPL license. I think this is a good strategy because it can ensure the long-term success of the Frappe Ecosystem.

However, there are some questions that I think have to be discussed:

  1. Do Frappe Framework apps that are installed into the same Frappe site contaminate each other license-wise? This was not an issue before, because the GPL viral clause is only triggered upon software distribution, but with an AGPL app in the mix this could mean that a company has to release the source of its private apps (e.g. internal tools) to the users of e.g. the CRM or Ticketing app, because they are running in the same Python process.

  2. If app X depends on the doctypes of an AGPL-ed app Y, then does that mean that app X must be placed under AGPL as well? My first instinct was “yes”, but what if that app only uses the doctypes with the REST API? In that case I don’t think it does.

  3. What is the “public API” of a Frappe app, which can be used without triggering the viral nature of xGPL licenses?

These licensing issues are very much affected by the Frappe software architecture where multiple apps are running in a single process.

This is not a new situation in the software world, and there is already a well-known solution to it in the Java ecosystem called the “ClassPath-exception to the GPL”, which allows a GPL-ed library used in an app inside the same VM, without triggering the viral aspect of the GPL.

I think that there should be clear licensing guidelines defined for Frappe apps and if necessary, a “Frappe Exception” introduced to solve any licensing issues that are caused by the unique software architecture of the Frappe Framework.

What do you think?

Kind regards,
Gergely Kis
(CTO of Migeran)

4 Likes
2

I hope we receive clear guidance on all your questions, and let me add one more to the list: If there is no external app, because in a no/low-code framework, if we add extra fields and server/client scripts through the UI, that means there is no app, no code, and those modifications don’t have to follow XGPL rules, correct?

I thought this because I found a very similar analogy from @rmehta here:

3

(Shifting here from the other thread)

I’m definitely not a lawyer, but I’m reasonably confident that there is no issue here. The functional structure of the Frappe framework would make the AGPL very permissive in this regard.

What you can’t do is straightforward: You can’t fork Helpdesk and sell subscriptions to your modified version of the app without releasing your modified code.

But, if you have a separate app with no shared code, you’re not doing that. Even if you’re consuming data produced by an AGPL app or extending its functionality with new doctypes, this is all happening over published APIs. You’re not modifying the AGPL software itself. I don’t see any reason to think the AGPL would apply.

1 Like
4

Discaimer: I am not a lawyer.

In spirit of license: Everything that depends on GPL/AGPL code to do significant amount of work should be licensed as such.

  • Any app that’s just built on top of Framework doesn’t have such requirements because it’s MIT licensed.
  • Any app built on top of GPL code like ERPNext and is just delivered over network doesn’t have this requirement.
  • Any app that’s built on top of AGPL code like Frappe Builder and delivered over network does have this requirement.
  • Any app that is delivered to close group of customers only needs to be made available to that close group and no one else. The viral logic of GPL licenses only applies when you start “distributing”.
  • Any app that’s just installed next to AGPL app but doesn’t depend on it has no requirement to comply to AGPL.

https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietarySystem

You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a nonfree system, it would have the effect of making the GPL-covered software nonfree too.
A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.
However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.
The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can’t treat them as two separate programs. So the GPL has to cover the whole thing.
If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.
If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.

AFAIK we have no intention to add an exception here. AGPL was deliberate choice for new apps.

Any app that depends on our AGPL licensed apps is most likely plugin or services that won’t survive without the app. So they should be licensed as such if they are to be offered to public as a product/service.

4 Likes
5

Ankush, is this Frappe’s official stance? Does “should” == “must”? It’s definitely not a standard interpretation of GPL/AGPL, at least not as I understand them.

1 Like
6

I quoted FAQ from GNU only. Requoting the important part:

A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all.

In GPL, “delivery over network” isn’t considered “distribution” so you can depend on ERPNext and not make your app GPL. AGPL applies to delivery over network too.

1 Like
7

Google banned AGPL for this reason: AGPL Policy  |  Google Open Source

The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed. Because Google’s core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner.

1 Like
8

“Incorporating” and “depending on to do significant work” aren’t the same thing, though.

The question here is not code that is “copied from or derived from AGPL-licenced code.” Copying-and-pasting code would clearly be in violation of the license. The question, rather, is apps run adjacent to AGPL apps with no shared code but possibly consuming their data or sending data to them.

As you quoted earlier:

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

In this regard, the Frappe framework acts as a mediator between AGPL and non-AGPL apps. Are you saying that Frappe does not consider this mediation “arms length”? I’m surprised by that implication, so it would be great to get some clarity.

1 Like
9

@peterg

Lets use an example of using AGPLed code like Builder:

When you do frappe.get_doc("Builder Page", ...) aren’t you effectively using builder as a library? You’re not just exchanging data here, you get access to class defined inside builder, you can execute builder code with it and so on.

In this case that get_doc is effectively same as:

from builder.doctype.builder_page import BuilderPage
page = BuilderPage(...)
2 Likes
10

If this is Frappe’s stance, I hope you’ll make it publicly explicit. I don’t think I’ve ever seen this stated anywhere before. I don’t agree with your interpretation, but it is significant if this is Frappe’s official position. Even as GPL, there are huge implications for ERPNext here as well.

1 Like
11

If this is Frappe’s stance, I hope you’ll make it publicly explicit.

I’ll talk to others and draft a document. In any case, we are not litigious about licenses so far :smile:

I deliberately used “In spirit of license”.

If you need your product/service to be proprietary while depending on AGPL code, you SHOULD get it checked by lawyers.

5 Likes
12

Someone else can still sue you for license violation, our interpretation doesn’t matter.

E.g. Software Freedom Conservancy sues Vizio for GPL violations | ZDNET

1 Like
13

In principle we are very much for the idea of free software and that the primary goal of free software is freedom and not making a business. Our new licenses reflect that.

Though we have not explictly mentioned, applications that are used by end customers are AGPL and pure developer tools (like Frappe UI) are MIT.

Maybe like how @ankush said, we will make a policy around this, but hope this is clear in principle.

5 Likes
14

Frappe’s commitment to open source is clear and beautiful. I’ve really admired the organizations ethos, long after I came to enjoy the framework.

I think where things get less clear is what counts as “incorporating” AGPL/GPL software.

In Ankush’s example, I appreciate that a get_doc call and an import statement are functionally very similar. Functionality aside, though , I’d still argue that they’re different in important ways. It’s been explained to me that way by people much smarter than I am, at least. A public API is by definition public, a way for two bits of code to talk to each other without being the same program. Even if whole class objects get exposed, a public/private interface is still being crossed.

If Frappe’s stance is that class access is the threshold here, I’d wonder about Rushabh’s earlier statement about Builder pages. If they make API calls that return class instances, wouldn’t they also have to be licensed AGPL? If I write a server script that interacts with HRMS data, do I have to make it conspicuously available to anyone who uses my site? To push it even further, what happens when the Frappe app calls Helpdesk doctype methods?

I don’t make a dime selling software or development services. I’m just an enthusiastic end user. I do think there are some high-stakes ambiguities here, though, that only Frappe is in a position to clarify. A statement about how Frappe understands the AGPL to affect sibling apps would go a long way, I think.

3 Likes
15

This is an interesting question, specially for Builder because Builder is both the design and publishing tool. Builder pages though I reckon are not derivative of Builder (just like documents written in say Libre Office are not derivatives of Libre Office) and should not be subject to the AGPL.

Maybe we can license Builder under a more permissible license, or separate the Builder into a build and publish tool, or maybe just port the builder publishing part in the Framework itself so the publishing API is not subject to AGPL. Thoughts @surajshetty @ankush

2 Likes
16

@ankush

When you do frappe.get_doc("Builder Page", ...) aren’t you effectively using builder as a library? You’re not just exchanging data here, you get access to class defined inside builder, you can execute builder code with it and so on.

What if you do the same thing over the REST API that Frappe Framework provides for every Doctype? The standard interpretation of any GPL license (including AGPL) is that this is allowed usage, and does not trigger the viral clause in the license.

There is little functional difference between calling frappe.get_doc() and using the REST API, except it is a bad practice to go through the REST API if both apps are running in the same process.

This is exactly my 3rd question in the opening post: what is considered the public API of a Frappe app? Is it only the REST API, or is there also an in-process API provided by the Frappe Framework?

My instinct would say that the public APIs are:

  • APIs available out of process (autogenerated REST API, controller methods whitelisted for network usage … etc.)
  • Doctype definitions (these are required to use the above APIs as well and to make sense of the data provided by the app)
  • Any in-process APIs that allow the user to access the functionality of the app but not alter it in any way.

For Example, it should be fine to use frappe.get_doc() or the Query Builder to get access to the data stored by the app, or execute the logic defined in the app using API entry points.

However, in my opinion, it should be regarded as derived work (and trigger the xGPL viral clause) if:

  • custom fields or other customizations are added to an app
  • the computation logic of the app is modified through some framework means (e.g. hooks, client and server scripts)
  • application code is directly used by the other app (e.g. using import)

So in my opinion there are many parts here that require clarification and clear rules.

17

Software Freedom Conservancy usually represents specific developers whose GPL licensed code was incorporated into the Linux kernel, U-Boot, Busybox … etc. It is not like they are going around and randomly suing companies failing to release GPLed code.

So while it is true that any Frappe user could sue over a GPL violation, they would have a much weaker case, if the service provider/software vendor adhered to the clear licensing guidelines and license interpretation of the original developers of the used app(s).

1 Like
18

This is the standard interpretation: when someone publishes a page with Builder it is pretty similar to using a GPLed C/C++ compiler to build a proprietary software: it is acting as a data processing tool.

I don’t think that is necessary for the whole app. However, if the Builder includes AGPL javascript code libraries in the published pages, that could cause issues (I have not checked if this is the case).

It is standard practice with compilers that the runtime libraries that are used in the compiled programs are released under a less strict license (e.g. LGPL), while the rest of the compiler is covered by a strict copyleft license (e.g. GPL / AGPL).

1 Like
19

I’ve done a bit more digging on this and talked to our lawyer. A few notes for those interested:

First, I agree fully with Frappe Inc.'s decision to put new apps on the AGPL. The GPL just didn’t anticipate the rise of SaaS, and AGPL fixes that. This is the right license.

But, there is a question that requires clarification: on Frappe instances that use AGPL apps (Helpdesk, Builder, CRM, etc.), what are the licensing requirements of other apps on the same instance?

In broadstrokes the AGPL is clear.

  • If a program uses AGPL code as a library, that program must also be AGPL.
  • If a program interfaces with an AGPL program via an API, that program is not obligated to be AGPL.

The specifics, however, get messy. Here, the specific question is: Are Frappe apps programs or libraries?

In this thread, I believe Rushabh and Ankush are saying that Frappe Inc. regards apps to be libraries. I don’t agree with that interpretation, but also don’t have the legal or technical skills to argue the point with confidence. If true, however, the consequences are very significant.

If Frappe method calls like frappe.get_doc are understood to spread AGPL, all code on the same instance would also need to be openly published under the AGPL. This would likely include any in-house custom apps (even if they don’t interact with AGPL code directly) and all server scripts.

This has huge implications that go far beyond proprietary “for profit” apps. It means that if you use an AGPL frappe app on your instance, every single person who has access to that system has a legal entitlement to all other code on that instance. Offering the code on demand isn’t enough, either. According to section 13 of the AGPL, all code must be “prominently offer[ed]”.

My lawyer has advised me that, if we want to use AGPL apps and don’t want to dispute Frappe Inc’s interpretations, we would need to:

  1. share all of our apps and server scripts on a public repo,
  2. make sure that they stay up-to-date, and
  3. prominently advertise them on our site.

He adds, this obligation applies even for private, in-house stuff that we have no intention of selling or distributing.

Is this the intended effect of the move to AGPL on new apps? If so, I hope people are aware. If not, some clarifications might be needed.

2 Likes
20

Thank you @peterg for confirming the issues I have been raising in the starting post of this topic.

I think the best way forward would be the introduction of a “Frappe Framework Exception” to the AGPL license (Similar to the ClassPath Exception in the Java World), which would clearly specify what kind of interactions between apps would classify as “interfacing over an API”, and which would classify as “using the code as a library”.

Until then, AGPL code should be executed in separate Frappe sites in separate Python interpreters from all other code, and only interfaced with through network APIs (e.g. the REST API).

1 Like