Hi
Suppose I develop a new application using Frappe framework, what is my freedom to license my app. Should it be MIT/ GPL or can even be proprietary?
Again would the answer be different if I have used certain modules of ERPnext in my new application?
Kindly share your insights.
It will help me and also others to decide on vital issues
Thanks and regards,
Deepak Gupta
No input on this?
If you look whatâs happening at odoo where you can see a growing fog around what actually is legal (and maybe regard that as âsomething to avoid fir ERPNextâ) an answer on this question is obligatory.
The Frappe Framework has an MIT License, so if you create an app based solely on Frappe (without using ERPNext) then I believe you have freedom to license your app however you want.
ERPNext is GPL (no version specified), so if you integrate your custom app with ERPNext, then the question becomes more difficult to answer - you would need to seek a lawyerâs opinion in your area. It would be up to a lawyer to determine whether the module is âderivativeâ.
Wordpress plugins may be a good comparison, but even in that case, there are many blogs online on either side of the discussion on whether a plugin has to be GPL or not.
erpnext/license.txt at develop ¡ frappe/erpnext ¡ GitHub says its GPL3
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
we are faced with with a similar problem. Itâs not all about licenses but about API Integration wit ERPnext.
We have a customer which runs a couple of custom internal backend systems exposing APIs like REST or SOAP. ERPnext should be integrated to automate Workflows for:
All these APIs are closed, behinf firewalls and VPNs an under subject of NDAs. So there is no need and no option to provide the code calling this APIs und der OpenSource. And even when there would be no access of the Community to theses APIs.
From a System Perspective we would like to see a app on the desk and settings managing this APIs in the same way you manage the other integrations.
How is the development model for that, Does developing such APPs it fall under the frappi.io MIT license or the ERPnext license. Obviously we are going to manipulation ERPNExt records like PO, PR, SO via the internal API.
Just as a side node, Integration libraries or functions to write such a integration like SOAP lib etc. would be OpenSource of course, but there is no way to drop code showing the semantics, endpoints or payload of the Integration APIs.
Please advise, many thanks,
Holger
Keep these in database or config files if you can.
e.g. Dropbox secret and client id is kept in site_config.json or Social login keys are saved in database.
@revant_one Sure thats a implementation detail.
How ever what a community would do with a ERPnext App which integrates a API which no one else has access to.
I think @revant_one is one of âhis guysâ
@rmehta an example why it might be beneficial to mark Frappe employees as such
@vrms thanks for clarification. But even then the answer is just about valuable data like API Keys, Enpoints etc. It stil does not answer the question for the code implementing the API adapter, As mentioned bevor I see no value to make the actual API implementation public as nobody will even access a Onternal IT system of a customer in charge of a production process not even known to them. Still I would say that underlaying technology like including a SOAP Lib would become Opensource.
@hwinkel As long as you do not distribute the code, I am not sure if GPL applies. Either ways I am not an expert on licenses. Apps / plugins are always grey area.
Philosophically, personally, I would prefer everything open as it encourages collaboration, learning and spreading of knowledge. Maybe you can break your enhancements in way that generic improvements are made public and very specific implementation details are kept in a separate app that is not redistributed. Again, donât take my word for this 
@vrms, @revant_one is an independent service provider! Either ways as far as interpretation of the GPL is concerned, I am not sure how this matters.
@rmehta thanks for the reply. Iâm just study the internal API we need to implement. Trust me you canât learn anything from this API âstyleâ. We will start to put it in a app to have this separated. If we need to make it public we need to move away to another tool anyway because this would not be allowed by the customer. As you said this is always the problem with apps and plugins. I would always open source integrations with any kind of public Service. But In case where we hitting a internal industrial control system API we would never publish the code as we are definitely never ever allowed to. Regardless how good or bad the API might be. If it required to do so we must move away from integrating this as frappe app in ERPnext and look for some other options.
To get this right, The question is not about commercials, pricung etc etc. Itâs simply the fact that we could not publish code in public which implements APIs which are subject to NDA. of course the customer receiving the work could receive the Code to. But it would be never allowed to make the code public available.
And BTW, while moving towards more and more to protocol based integrations the whole Question of linking in Code in particular languages becomes irrelevant. From broader scope, what is the difference for a system perspective of using a REST based HTTP HAL Link to call another function or calling a python module or linking C code. Technical Iâm quite aware of the difference but from a âSystemâ perspective both solving the same problem but a handled totally different from a License Perspective.Thats the mess we are in, and that why our code is either commercial or MPL/MIT, other wise we would waste energy discussing that and delay adoption.
Just my 2ct. 
Iâm founder of MN Technique, ERPNext Service provider.
Unless there is some showcase/repo online and the interested users or developers are directed where the hosted repo is, only few will know about the software.
All of our software is open sourced, even the rest api for custom requirement.
For a customization we wrote an endpoint which accepts rest api call from a specific call center software.
This call centre API is not as specific as internal API you are talking about. So except for the FOSS and pro-community principle, there is no need to open source the software.
Recently @Anish_Gupta could scan through the code we shared for call-center API. This was not planned.
Generally people who accept and know the power of free and open source Frappe/ERPNext, donât mind keeping the apps open source.
We are about to setup a company that will work on apps connected to Frappe/ERPNext. All apps are to be open-source. My problem now is that third-party integrators on the app may or may not share their codes as they will use APIâs from the open-source app. Any problem on licensing with this?