Less restrictive licence

[robhawkes]

Hi Jan,

First off, thank you for pulling together this project as I've been excited about having up-to-date versions of PROJ and Spatialite in WASM (and the browser) for some time.

One problem I have is that the current GPL-3 licence makes it impossible to use WASM files from this in my own non-GPL projects, especially if I want to customise the source (eg. to generate isolated WASM builds for PROJ). While I have no problem with releasing any customisations under an open licence, I wouldn't want to infect the rest of my codebases with GPL-3 simply by using the generated WASM files from this project.

Would you be willing to consider moving to a less infectious licence? Perhaps LGPL, or MIT like your previous iteration of the project?

I understand if not, though it would be great if there was some way to tweak this as I know a lot of people would love to use and share the work that you've done here so long as it doesn't interfere with their existing codebases.

Either way, keep up the great work here with the WASM builds.

[jvail]

Hi Rob,

I am not sure how to efficiently solve the issue since the GPL is forced by rttopo: the wasm files that I distribute here must be GPL because rttopo is part of the distribution. For the distribution I need to follow the spatialite licensing. So - in theory - I could choose another license if I would offer a second build without rttopo. I'd like to avoid this.

I could at least release my own code under a different license. Still you would need to compile your own build without rttopo. Any suggestions?

I have not followed the most recent development in emscripten. I guess, If there would be an option to dynamically load rttopo (or not to keep the code LGPL'd) the problem could be solved without a second build.

, especially if I want to customise the source (eg. to generate isolated WASM builds for PROJ)

Are you trying to build only proj without spatialite or are you trying to include a modified proj build into spl.js?

[kylebarron]

Speaking for myself, I'm interested in a standalone WASM build of PROJ. At this point, spl.js is the only project I've seen that has compiled PROJ to WASM. I'd be interested in forking parts of the Makefile to try and get the Rust PROJ bindings built for WASM (see georust/proj#115) but not sure if I could do that from a GPL-3 licensed project.

[jvail]

@kylebarron
Not sure I understand what you are trying to do but from what I have read it might not be possible to combine emscripten built wasms with rust wasms (but things change quickly so there may be a way now).

First of all: I have no objections releasing my code under any license. What I need to solve is how to provide multiple builds with different licenses. In theory I could think of several dists (probably in a github organization with multiple repos)

• including rttopo (GPL)
• including sqlite, spatialite, proj & geos (MPL, LGPL ..)
• with minimal geo capabilities: sqlite, spatialite & geos (MPL, LGPL ..)
• including only sqlite & proj?
• including only sqlite?

I also see an advantage in providing smaller dists (~1-2 MB maybe) along with the full build.

[kylebarron]

I'm essentially just looking for a standalone PROJ Wasm build (trying to keep the bundle size as low as possible). I'm not sure if it's possible to link two separate wasm executables without going through JS, but going through JS in between is still worth it to have full PROJ in the browser. 🙂

including only sqlite?

Sql.js seems to be well-supported, so not sure if a sqlite-only build would be necessary.

I'm not a laywer but I'd like to think it would be possible to designate different licenses for each part of the code without separating into separate bundles 🤷‍♂️

Regardless, this is a really cool project 🙂

[jvail]

I'm essentially just looking for a standalone PROJ Wasm build

Then why not just build it yourself? Copy the part of the Makefile you need, do your modifications and make a proj build and release it under a proj compatible license and leave only the Makefile GPL (if you think this is necessary to comply with my project) - et voilà.

[kylebarron]

release it under a proj compatible license and leave only the Makefile GPL

Honestly I didn't know this was generally possible 😅 I just assumed that taking any GPL code would require the whole project to be GPL.

The next couple weeks are pretty busy for me, but I'll let you know if I make progress with any wasm bindings!

[jvail]

Honestly I didn't know this was generally possible sweat_smile I just assumed that taking any GPL code would require the whole project to be GPL.

I never thought about it either. But since it is only a Makefile, I guess, it does not matter.

The next couple weeks are pretty busy for me, but I'll let you know if I make progress with any wasm bindings!

Sure - good luck.

[jvail]

including only sqlite?

Sql.js seems to be well-supported, so not sure if a sqlite-only build would be necessary.

I thought about this and I believe a dist with only sqlite + the geopoly (https://www.sqlite.org/draft/geopoly.html) extension (sqlite with minimal spatial features) may be interesting.

[willcohen]

Hi there -- I went down a bit of the rabbit hole this past week trying to see if I could adjust my emscripten build of PROJ to build as pure wasm, but it looks like its use of threads means it's going to require JS no matter what until pthreads land in webassembly proper.

The hardest part for me has been to ensure that whatever wasm comes out of PROJ is widely usable. Requiring JS works on the browser, but it would have been nice to have a pure wasm for other wasm runtimes. For now, then, I know I can target the browser with WASM + JS, and graaljs by transpiling the wasm back to JS too, but things like graalwasm are for the moment excluded.

@kylebarron what use case are you looking for? My plan is to create both a .jar (using both native PROJ and emscripten PROJ as a fallback) and a node package (emscripten only, of course), so that the JVM and javascript VM can both stay in sync with native PROJ. I'm doing it in clojure/clojurescript, so both VMs are targeted with the same project. If that meets your needs and you can hold tight a few weeks, I'll get the POC posted (with at least creation of CRSs and transforming arrays of coords) and get a first draft packaged up soon!

[Rennzie]

@willcohen interested to know if you managed to get a full version of PROJ to compile to wasm for the browser?

[willcohen]

Compile — yes. However, all the C-level allocation and freeing of emscripten arrays creates a serious impedance mismatch for JavaScript users. I’m still working out how best to track these resources and make sure they get auto cleaned up so memory doesn’t leak. Once that’s done I think it’ll be usable as a first pass.

[Rennzie]

Amazing. Pretty excited to see this. Have you got a GitHub link I could sneak a peak at?

[Rennzie]

Hey @willcohen, I'm wondering how you're getting on with your PROJ => Wasm attempts? Have you got a link to a repo I could follow?

[willcohen]

Apologies for the delay. I got stuck down a major rabbit hole sometime in January where the static linking / dynamic linking settings for libtiff vs sqlite caused some issues with the WASM module's dynamic modules, and I got stuck there. I got emscripten bumped to a more recent version (was on 3.1.24) and hope to get this a little further. It's all the small stuff! Once I re-unbreak the build after this toolchain update and get something built (even with issues running) in WASM I'll get it posted asap. Lots of moving pieces!

[willcohen]

@Rennzie additionally -- how are you hoping to consume this? Is it via Javascript? Would your final preferred output be an npm package?

[jvail]

@willcohen could you continue your - certainly interesting - discussion elsewhere? Thank you