Hi all, I’m just wondering - is it within the license terms that we’re allowed to open-source an app made with Wappler?
I understand that to be of most use, contributors should also be using Wappler; I just want to make sure this is okay.
Thanks in advance.
I believe anything you create in Wappler would be your own to do with as you wish. What kind of app are you thinking of?
It’s more the use of App Connect etc., I’m unsure of the licenses surrounding the server & client-side libraries, especially if checked into version control on a public repository.
Well there is no much sense in open sourcing it, as the users will need Wappler to edit it.
If you decide to open source it - it is ok but please do mention it needs Wappler and do not include the dmxAppConnect and dmxConnectLib folders as those are distributed with Wappler only for now.
They will be auto created when the users open the app in Wappler.
Just as I feared. What if a Wappler user builds a web app and intends to distribute it for free (not necessarily under an MIT license) so that non-Wappler users can simply install the web app on their servers, are you saying this is not permitted?
If so, then that is a shame…
Nothing to worry! You can include the full App Connect and Server Connect code to your app open source distributions.
We plan to open source App Connect and Server Connect ourselves just haven’t got enough time yet to do it right.
By open sourcing those two frameworks we hope more people will create app connect components for the frontend and also more server side languages support will be added to the server connect as backend.
We also hope that more unit tests will be added so that the frameworks become rock solid.
So we hope to do it soon and can use any help on it!
Awesome, many thanks! 
Has there been any movement on open sourcing App Connect and Server Connect?
If not, would it be possible to at least reference them in the Wappler Terms and Conditions?
There is currently no reference to either framework in Wappler’s terms and nothing that explicitly states that the frameworks can legally continue to be used to power a live site/app even if the site/app maker is no longer subscribed to Wappler.
Some development clients are fairly knowledgeable and ask questions like what frameworks will you use, what type of licenses do those frameworks have, etc. It would be nice to be able to point them to the Wappler terms and show them clearly that App Connect and Server Connect can legally continue to be used even without an active Wappler subscription regardless of whether or not the two frameworks have been open sourced yet.
It would be very helpful if we could access the unminified App Connect sources, given the lack of comprehensive documentation.
For example, to really understand how to use dmxFormatter.js, we had to prettify it, but it was hard to read because of the minification.
We are also not getting all the source map files for every version of AppConnect and related code somehow, leading to a bunch of warnings in the browser console, like these, which obscure important error messages:
DevTools failed to load source map: Could not load content for https://***/dmxAppConnect/maps/dmxBootstrap5Modal.js.map: HTTP error: status code 403, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load source map: Could not load content for https://***/dmxAppConnect/maps/dmxBootstrap5Offcanvas.js.map: HTTP error: status code 403, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load source map: Could not load content for https://***/dmxAppConnect/maps/dmxBootstrap5Alert.js.map: HTTP error: status code 403, net::ERR_HTTP_RESPONSE_CODE_FAILURE
DevTools failed to load source map: Could not load content for https://***/dmxAppConnect/maps/dmxBootstrap5Toasts.js.map: HTTP error: status code 403, net::ERR_HTTP_RESPONSE_CODE_FAILURE
I’d also add, that App Connect is perfectly usable without the Wappler app (after using the Wappler app long enough to learn the DMX expression language).
In fact, more complicated DMX expressions are easier to edit as text, as opposed to Wappler’s visual editor, which was mixing up the treatment of JSON keys, which contained dots and slashes.
Our Wappler app is consuming data from a Clojure app, through a JSON API, so the keys of our JSON objects are often namespaced, eg:
{"flow.destination/app": ":app/google-sheets",
"flow.destination/ref": {"and/so": "on"}}
The team is already on it: