Frappe Licensing & Software Architecture

[peterg]

For what it’s worth, the more research I do, the more I disagree with Rushabh and Ankush’s interpretation here.

The name of the page defining the get_doc interface is “Document API”. Calls are made via a well-defined, non-AGPL pathway, and anything access this way is made available by app designers. It is possible to write code that is not accessible to the Frappe APIs.

But, this gets very technical, and for that reason author’s intent does matter. I hope we get some clarification. The compliance obligations for in-house apps/scripts are pretty enormous, and it’s hard to believe that’s the intention.

[rmehta]

@peterg

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.

Can you share the specific passages where we say this?

Any website / web-app built using Builder does not become AGPL if it only uses API calls, the same way any application that runs on Linux does not automatically become GPL (all apps running on Linux use Linux API)

The goal behind making these apps AGPL is that anyone who runs modified versions of Builder or CRM should give the same rights to the users, anyone who uses them as API backends does not have to make their applications AGPL.

Hope that is clear.

[kisg]

@rmehta

Can you share the specific passages where we say this?

@ankush wrote this a couple messages before:

@ankush

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(...)

@peterg and I disagree with this, because frappe.get_doc() is part of the public Document API provided by the Frappe Framework, it provides the same functionality as the REST API provided by the Frappe Framework. The only difference is that the Document API works only in the same Python process - but can easily access the Documents created by any App installed on the same site - this is one of the superpowers of Frappe Framework.

The second example is, in my opinion, using internal code, that would make the other app a derived product of the Builder app, and thus trigger the viral clause of the xGPL licenses.

Maybe we should look at a different example: the CRM App.

What if someone wants to create a custom, company specific, internal integration between ERPNext and the new CRM app. According to the recommended approach, they package this custom integration as a separate Frappe App. They have 2 options:

• only use the REST APIs to communicate with the CRM app and ERPNext with no other interdependencies. In this case the App can even be installed on a separate site (possibly on a separate server).
• install all 3 apps on the same site, but only use public Frappe Framework APIs (Document API, Query Builder API … etc.) to create the integration between CRM and ERPNext.

The first option does not trigger the AGPL viral clause for the internal app, because it is only using network APIs.

However, the second option triggers the AGPL viral clause, if we use the standard interpretation of application boundary == OS process boundary (in our case the Python interpreter).

If it would be clarified, that for a Frappe app, the application boundary is the Frappe App boundary (and public APIs) defined by the Frappe Framework, and multiple Apps can coexist in the same OS process (Python Interpreter), then the AGPL viral clause would not be triggered for the internal app.

The reason why I am advocating for an AGPL license extension that clarifies this (like the Java ClassPath GPL Exception that serves a very similar purpose), is because even if Frappe Inc. agrees to the above interpretation, any external contributor whose PR(s) were accepted into an AGPL app could sue anyone, who uses the app as I outlined here.

[peterg]

@rmehta

Can you share the specific passages where we say this?

Ankush and I have quite a bit of back and forth in this thread where that seems to be the message, at least as I understood it. The most explicit bit is probably the part @kisg quote right above me here.

I had asked if Frappe regarded API calls as sufficient “separation”:

@peterg

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” [per the A/GPL license]? I’m surprised by that implication, so it would be great to get some clarity.

Ankush’s responded by saying that get_doc is effectively the same as a library import. That distinction is extremely important in the context of the AGPL.

@ankush is an amazing software engineer who does huge amounts for the Frappe community, so I certainly value his opinion a great deal (even if I disagree with the specifics). Whatever Ankush’s personal view might be, though, the more important question right now is Frappe Inc.'s interpretation

When you joined the conversation, Rushabh, you didn’t get too far into the technical details, but you seemed (to me, at least) to be confirming Ankush’s interpretation, especially when talking about restructuring builder to use a different license. If framework api calls don’t spread the AGPL, I don’t think that would be necessary.

@rmehta

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

It seems things definitely aren’t yet clear!

In any event, I’m glad to learn this might just be a miscommunication.

[wale]

Interesting conversation…

@peterg

I had asked if Frappe regarded API calls as sufficient “separation”:

@peterg

In any event, I’m glad to learn this might just be a miscommunication.

I’m not sure if an answer on this forum would actually suffice. As @kisg mentioned, it may be important to explicitly include this understanding in the license

Kind regards,

[rmehta]

@kisg

The reason why I am advocating for an AGPL license extension that clarifies this (like the Java ClassPath GPL Exception that serves a very similar purpose), is because even if Frappe Inc. agrees to the above interpretation, any external contributor whose PR(s) were accepted into an AGPL app could sue anyone, who uses the app as I outlined here.

Seems you are an expert in this. Can you help us draft one? We can include it in the license file.

The intent is that an direct derivatives of these apps should be AGPL, not those using the API without changing any core functionality.