What is the license of NetTopologySuite.IO.ShapeFile?

[pauldendulk]

On nuget it says the license is LGPL: https://www.nuget.org/packages/NetTopologySuite.IO.ShapeFile/ While NTS itself is BSD3: https://www.nuget.org/packages/NetTopologySuite/

Will the license of ShapeFile also be moved or is there a reason it should stay LGPL?

[DGuidi]

All other NTS modules (actually, I just checked some of the modules, like features, geojson, postgis, and so on...) have a license file that match BSD license. shapefile module is LGPL, as you may see also in the csproj. I think that the reason is that the IO code basically is started - many years ago - as an adaptation of GeoTools.NET and followed the same license, that was the same used also to JTS (and NTS) at the time. Now, I don't have any objection to move to a different license, but honestly I have not idea of the approvals needed. GeoTools.NET was - at the time - a not-supported project and the code was heavily modified from NTS developers, that added also a lot of features.

[airbreather]

Now, I don't have any objection to move to a different license, but honestly I have not idea of the approvals needed. GeoTools.NET was - at the time - a not-supported project and the code was heavily modified from NTS developers, that added also a lot of features.

From my understanding, even with all the enhancements and fixes, this still technically counts as a derivative work, so we would very likely need approvals from all copyright holders of the original work in order to change from LGPL 2.1 to BSD-3-Clause.

I still work at Urban Science, so I could pretty easily try to get written approval for relicensing anything that covers their own contributions in GeoTools.NET, but that project was itself a derivative work of something that has Vivid Solutions copyrights on it, so I think someone may need to reach out to those folks if we wanted to make this happen.

[FObermaier]

We could do the following:

• use @kubaszostak 's work on #69 for the Shapefile part (has signed CLA) and
• use Sylvan.Data.XBase for the dbase part (MIT)

I assume that this would doable within a reasonable timeframe.

[KubaSzostak]

If there is no time pressure I can resume work on #69

[FObermaier]

If there is no time pressure I can resume work on #69

That'd certainly be appreciated, but lets get consensus first.

[DGuidi]

that project was itself a derivative work of something that has Vivid Solutions copyrights on it

I can assume that the vivid solutions reference is basically JTS, as from docs page, so perhaps we can just ask Martin Davis @dr-jts for this. For GeoTools.NET, we can try to involve Andrew Coats @awcoats

[DGuidi]

I assume that this would doable within a reasonable timeframe.

I would like to move the actual code to another license, if possible of course. No bad feelings about the new improvements, but removing the old code basically means doing another library, so maybe if this the only alternative available, we can think of a different package with a different name. Just my opinion.

[KubaSzostak]

In my opinion there was a good reason for issuing Redo everything #48. The current API is horrendous. I found it easier to rewrite it from scratch rather than use current implementation. See also API review #42 discussion.

[dr-jts]

that project was itself a derivative work of something that has Vivid Solutions copyrights on it

I can assume that the vivid solutions reference is basically JTS, as from docs page, so perhaps we can just ask Martin Davis @dr-jts for this. For GeoTools.NET, we can try to involve Andrew Coats @awcoats

The JTS Shapefile code is a fairly modified version of the very old GeoTools code.

The code was relicensed when JTS moved to LocationTech EPL, and that's a more lenient license than LGPL, if that helps.

[DGuidi]

The code was relicensed when JTS moved to LocationTech EPL

NTS itself moved to another license - see #196 and #238 with references to IO code - so perhaps the code involved in NTS IO modules was ported from the same code relicensed when JTS moved to LocationTech EPL (using Martin words)?

[FObermaier]

@DGuidi, I don't see the point in keeping the current implementation that is hard to use, slow and has flaws. I'd be in favor of #48 and use #69 as a start.

[DGuidi]

@FObermaier I don't have any strong opinion against maintaining the current implementation. I'm just saying that, if it is possible with a small effort, I would like to move the old code to a different license, then add a new implementation and perkaps mark as deprecated the older one. In any case, this is just my opinion, and I don't want to block anyone and/or anything, also because my contribution to the project is minor.

[FObermaier]

Sorry to pull you in here, @airbreather, @xivk , @stijnherreman, but do you have an opinion on the proposition I made to

• use kubaszostak 's work on #69 for the Shapefile part (has signed CLA) and
• use Sylvan.Data.XBase for the dbase part (MIT)

or keep the current codebase and seek for permission to change the license?

[stijnherreman]

Note that XBase does not (yet) support writing, only reading is implemented.

As for the rewrite of the Shapefile part, I've since moved on to another (non-GIS) project/client, but maybe @kristofdegrave can provide feedback.

Relicensing can be a difficult and time consuming process when you need to track down all contributors. Personally I would opt for keeping the license of the current implementation and using the preferred license for the rewrite.

[kristofdegrave]

I would have to test this inside our own library. Since this is a radical (breaking) change, I would recommend to move the code to an other code base and package as mentioned before. This can then be marked as deprecated. I know my framework code has some tweaks to handle the reading of attribute values out of the dbfiles, for example to read int or long values I needed to add some custom logic.

Also I need to be able to read and write to streams. For this I added a solution to this project, not sure if this is provided inside the rewrite.

But if the new packages are available as pre-releases, I'm available to test them against my own code.

[KubaSzostak]

In #69 I have done dBASE part (reading and writing) on my own. I was using dBASE specification docs.

[airbreather]

do you have an opinion on the proposition I made to

• use kubaszostak 's work on Wip/redo everything #69 for the Shapefile part (has signed CLA) and
• use Sylvan.Data.XBase for the dbase part (MIT)

or keep the current codebase and seek for permission to change the license?

Yes.

In my opinion, we should keep the current codebase around, but in "bugfix-only" mode to support legacy clients, including any further updates that newer versions of NTS might justify.

IMO the current API is bad enough to justify splitting off a new "NetTopologySuite.IO.ShapeFile2" project for new development going forward, as probably almost none of the existing stuff is "good enough" to remain as-is. I had originally intended to do this myself in my free time, but not much of my free time has been going towards NTS...

Looking at how Sylvan.Data.XBase works at a technical level (and only at a technical level at the moment), I fully support taking a dependency on this project for the .dbf parts of shapefile reading. I don't think it's worth it for a general-purpose library to try to do any better than this.

---

Because I promote "freezing" what we have right now and focusing energies on a new "ShapeFile2" project (which, it should go without saying, really shouldn't have a less permissive license than other new NTS projects), it doesn't seem worthwhile to spend the energy on relicensing the crusty old bits, since the license of the existing library only realistically matters to people who are already using what we have (or people who start using it between now and when the new thing is ready), and so they fall into one of three categories; they're either:

• complying with the requirements of LGPL-2.1 (which, for all intents and purposes, basically means that they're already complying with the requirements of, say, BSD-3-Clause),
• violating LGPL-2.1 in a way that does not also violate (say) BSD-3-Clause and so we don't really care about the violation, or
• violating LGPL-2.1 in a way that does also violate (say) BSD-3-Clause and so relicensing doesn't really change their situation

In all 3 cases, it doesn't seem to actually help anything for us to make the license more permissive...

[FObermaier]

I don't see the point in creating a ShapeFile2 project. The way I see it we should

• stall the development of the current develop/master branch pair in v2/master and v2/branch,
• develop new Shapfile IO in this project and raise version to v3.0

Anyone having a need for the current implementation but use a newer NTS version that'd be incompatible to the current package would be on his own, but I'd have no problem with that. I strongly dislike versioning in package names.

[airbreather]

IMO that approach made sense for v1 --> v2 stuff, because although there were several significant breaking changes, it was still "just" a new version of the same code. There was a clear migration path from the one version to the next.

The new shapefile IO project would solve the same problem with a completely different codebase that shares essentially nothing with the current codebase. It's not so much "the next version of the same thing" as "an alternative way to do the same thing" — kind of like how JTS has both Overlay and OverlayNG (though that particular naming annoys me now, because the new one is only the "Next Generation" until it gets merged, but then all the code that uses it will have to call it "next generation" forever). GeoJSON / GeoJSON4STJ is kind-of in the same boat as Overlay / OverlayNG, although people are going to be on Newtonsoft.Json forever, so it's not quite the same thing.

Anyway, I don't mind letting the old shapefile project just sit there getting practically no attention. (Edit: bah, I clicked the Close With Comment" button because my finger slipped... )

[kristofdegrave]

Wouldn't if be an option to loose the name of ShapeFile and use the name of Esri instead (since this package is bigger than shape files alone crf DbaseFiles). Also I see an implementation for Geodb files.

(Also the new projects are called Esri ...)

just my 2 cents

[FObermaier]

So there seems to be consensus on

• not to evolve the code in this project any further, don't attempt to change the license for this project.
• create a new project that hosts the yet to emerge shapefile io code
• start with @kubaszostak #69 code.

@pauldendulk, license for this project will stay LGPL2, there will be a new one with a more permissive license, probably BSD3

[xivk]

Just FYI, I read the thread and agree with your latest summary @FObermaier

[KubaSzostak]

So what would be the further steps? Should I create new a project in NetTopologySuite.IO.Esri?

[FObermaier]

@kubaszostak , that would be great. I'd prefer a fresh start with just the following projects in src

• NetTopologySuite.IO.Esri.Core
• NetTopologySuite.IO.Esri
• NetTopologySuite.IO.GDB

and

• NetTopologySuite.IO.Esri.Test
• NetTopologySuite.IO.Esri.TestConsole

in test

I'm not sure right now if there are tests for NetTopologySuite.IO.GDB somewhere in NetTopologySuite.IO.ShapeFile.Test, they'd need to be moved to a seperate test project.

[pauldendulk]

Thanks for all the reactions! Such activity indicates a healthy community. I am happy we switched to NTS with Mapsui v4. Since our license is now MIT we will not take a direct dependency on NetTopologySuite.IO.ShapeFile, but users could still use it in their own Mapsui projects without too much effort.