I am working with Jaspar on a funding bid for an app he wants to develop for Locafora and Voetselteams. He had a technical question about how feasible it would be to link his new app to OFN. I do not have the tech knowledge to answer his question so have invited him to the OFN dev mumble on Thursday. Here is some background on his question
From: Jasper
Sent: 28 August 2017 15:31
To: Iris van de Graaf
Cc: nick@nickweir.co.uk; Bram Bergkamp
Subject: Re: Eurostars Open Food Network
Hi all,
Some background to what I was talking about in the call:
Our current focus is on a subsidy provided by Interreg. This subsidy has an āexclusivity clauseā: the subsidized intellectual property created through the funding must belong to the organization funded and be usable exclusively by that organization, creating a competitive advantage. This clashes with the AGPL license of the Open Food Network.
The current OFN implementation/architecture is based on a tightly coupled model (back-end and website are directly linked). A mobile app requires a decoupled architecture (REST-ful). The OFN REST API is currently a second-class citizen compared to the website and seems to be mostly focused on third-party integrations rather than user functionality. Should the REST API be required to offer the same functionality as the (tightly coupled) website, this furthermore means that two models (tightly coupled website + decoupled through an API) will have to be supported and kept in sync simultaneously. In our opinion something can be said for then rewriting also the frontend website to a decoupled model, using a frontend framework such as Angular/React/Vue/etc.
Best regards,
worth looking at the USA planning thread and what Greg (? i think) is doing in Colorado . . sorry, replying from email so donāt have direct links, but I think a conversation between them could be very enlightening. If you could respond and ping the right people would be great @NickWeir!!?
Here is an email from @iris who is working withJaspar. @NorthernColorado please could you update us on your plans. Thanks Nick.
This from @iris :
Jasper, Bram and me were discussing the options for working with OFN. We think that our main question is, if OFN is willing to:
Rewrite the frontend to a purely decoupled model, using a frontend framework such as Angular/React/Vue and a REST API. This will allow us and others to then write other frontend (such as apps) as well, as all of functionality of the website would be available via a an API. This would include all information available via the Spree API but also everything specifically OFN-related, along with user authorization and so on.
OFN is willing to consider relicensing to an LGPLv3 license instead of the AGPL license. This will allow us to develop our own platform on top of OFN where we contribute changes to the OFN back-end but create a frontend unique to us. This would go a long way to satisfying the exclusivity criteria of our sponsors.
These are fundamental questions. As we understand it, all frontend development on OFN is currently done with the use the (Spree) API and under the AGPL license.
Is it possible to get an answer to the above questions?
Iāve just read this more closely and realised that thereās a pretty ābig dealā legal question in there as well re. license.
If OFN is willing to consider relicensing to an LGPLv3 license instead of the AGPL license. This will allow us to develop our own platform on top of OFN where we contribute changes to the OFN back-end but create a frontend unique to us. This would go a long way to satisfying the exclusivity criteria of our sponsors.
These are fundamental questions. As we understand it, all frontend development on OFN is currently done with the use the (Spree) API and under the AGPL license.
I am not sure that the license change would actually be needed if you build your own front-end e.g. if it was a separate system calling OFN API then I donāt think OFN license would apply to it anyway. But if youāre asking OFN to rewrite our own front-end to make it easier for you, then obviously we want to retain full license over what we write for our front-end! and we would want to be able to use that new front-end to adapt for other people as well. hmmmm.
I think that if people want to have that discussion someone should āpresentā on it as next global hangout? and see if people think its something worth considering or not? @NickWeir@iris@MyriamBoure@tschumilas@Joel
From Coopdevs/Katuma we suggest the following actions:
keep AGPLv3 license for all the code already written and all the future code written by the community
develop a good OFN API (Spree API + OFN specific API) with AGPLv3 license
anybody will be able to develop its own frontend with whatever license they need (unless they mention OFN or use its code in any way) and point it to the OFN API
@iris please can you forward the conversation above to Jaspar (or even better ask him to join this forum). Also you or Jaspar are welcome to add this topic to the agenda of one of the following two meetings and then lead the conversation at the meeting.
I think we do want to go in that direction, as IMHO the product vision we have is to enable any user to have itās own website and integrate the modules she needs in this frontend, in their own specific design. I donāt know at all about what we need technically to achieve that vision.
About licencing, Iām not familiar with thoseā¦ I found very interesting those summaries of AGPL and LGPL
From my understanding, if we want to encourage the development of free softwares, I guess we should stick to AGPL, and also I think we have to given that multiples servers deploy our code. The only case when LGPL can be useful is if there are other similar solutions to the one we propose, so if prevent proprietary software to use it, they might choose the other solution, and it would not be (maybe) our interest as it would prevent the development of our solution. @Kirsten From my understanding, if you create just a front end and plug it to the OFN local instance server, you donāt make any new version of the OFN, you just plug to the server and call data through API, which in my understand doesnāt require any change in the licence.
But I think there is a different if a white label user make his own deployment and customize things in the source code (fork) then he has to share under AGPL licence, which I think is good. You can still contribute to changes i the back-end / common source code of the OFN, which will still be distributed under AGPL.
So, again from my understanding, I think we can stick to AGPL. But maybe I didnāt get the whole point
hi kristen. I am writing something that just relies upon the database rather than the whole application spree and ruby stack requirement. I anticipate a way to have a the most basic features available for low cost both hosting, setup, and updating / management scenarios. My work has kept me in the anglar4 /ionic3 app development world, I imagine having a free plugin to existing OFN sites, so they can export parts of the data they manage into āpayloadsā which run quickly and inexpensively within the app.
For a better user experience. I also envision a desktop app (via electron) that talks to remote micro services which act as intermediaries between existing or future OFN (spree commerce) postgres databases people have.
Hey all. Iāll briefly pitch in some thoughts on this topic from the perspective of using this to build a platform such as Locafora and Voedselteams.
First of all, short of rewriting the entire back-end, the AGPLv3 license will have to stay lest all contributors agree to relicense. What I believe is a good compromise to this, is to refactor the OFN back-end to be just thatāa back-end. It would no longer have any kind of front-end, but would instead expose all functionality via a well-designed REST API. The front-end can then be refactored with a decoupled approach, with e.g. Angular/React/Vue/etc. under the AGPLv3 as well. Similar to the approach mentioned by @enricostn, but with the extra step of splitting out all front-end code.
The benefit of making these two absolutely separate, as opposed to also maintaining a tightly coupled front-end within the same codebase, is that no functionality will have to be implemented twice or kept in sync. All back-end functionality would only exist in a well-designed and well-documented REST API. From an AGPLv3 perspective this then becomes a pretty reasonable network boundary, as the purpose of the back-end software will be to facilitate a REST API only.
This approach would then allow for frontends to be built under different licenses as well. Locafora and Voedselteams will be able to build a front-end (e.g. an Angular/Ionic app similar to @ecocity) which meets subsidy requirements from Interreg (solution has to be competitive). This would still give back well-documented and (reasonably) generically implemented improvements to the OFN back-end. And also allows Locafora/Voedselteams and others to pick and choose which OFN functionalities they would like to use or not use, rather than keeping (and obscuring) the whole range of features offered by the OFN platform.
I like this description @jasper and I guess that doesnāt prevent local āpublic instancesā to also offer the current frontend on their Saas offer. Or build any other frontend if they want. Iām not a tech person so I donāt know the details on that, but I have the feeling that would serve our vision to allow multiples standalone websites to connect to the OFN back end deployed as a mutual infrastructure that multiple front ends can connect with. @Augustin maybe that can fuel also our OFN evolution vision
For the communities i work with in the US and Kenya, having a JAM stack type of ( JAvascript- API, Metadata) system can cost $0/ month to run. This is the kind of budget that vulnerable communities can afford, so I am pursuing a decoupled stack that simply uses Firebase for authentication and back end primary service, with React as front end. I am using netlify to build my prototype. It is being done with spare time as-can do it endeavor.
my approach has been to inventory the interactions and features of OFN from the documentation and to use screen shots as a reference for building the forms and data bindingsā¦ I dream of efficient ( and super secure ) software.
more thoughts on āsplitting codeā in my comment to this thread 