Enforce GPL or LGPL conformity

Added by Florian over 5 years ago

I removed the TRIANGLE_D option in favor of a more general license restriction. This is the new implementation in cmake/ConfigUserTemplate.cmake:

# Enforce GPL or LGPL conformity. Use this to enable routines that cannot be
# redistributed under the terms of the GPL or LGPL such as Shewchuk's
# triangulation (valid values are GPL, LGPL and off) [GPL]:
#set (LICENSE_RESTRICTED off)
uncomment to enable Shewchuk's triangulation.


Replies (8)

RE: Enforce GPL or LGPL conformity - Added by Remko over 5 years ago

I thought I had already changes TRIANGLE_D to NON_GPL, in GMT5, or am I just dreaming?

Nonetheless, this is exactly what I had in mind.

RE: Enforce GPL or LGPL conformity - Added by Joaquim over 5 years ago

Sorry but I don't understand why we are referring to GPL since the license is LGPL and anyway setting GPL or LGPL does exactly the same.

But that is not the main issue. I would like to have seen this further discussed as there more related questions. Namely, how were the Win binaries built? With or without Shewchuck's code?
I remind that we had that discussion long time ago and decided to have the Win binaries with TRIANGLE_D and that is how, for example, GMT4 is distributed.

Also the installer that is currently on the forge to be released uses a GDAL build that has less drivers than the one that I built for GMT4 and prev GMT5b (jpeg2000, mrsid, fits, ogr drivers that will be needed when ogrread comes to live).
Another issue with that installer is that the GMT5_SHAREDIR env variable is appended to any existing instead of replacing. We cannot do that. because the later will be ignored (I think). Also the default installation dir proposed to the user should be the same that we have practise before "C:\programs\gmt5" instead of one that is revision number dependent.

Joaquim

RE: Enforce GPL or LGPL conformity - Added by Florian over 5 years ago

Sorry but I don't understand why we are referring to GPL since the license is LGPL and anyway setting GPL or LGPL does exactly the same.

Yes, right now there is no difference between the GPL and LGPL setting. The feature is designed such that future GPL-only code (e.g. new supplement additions) can be disabled by the LGPL setting. I'm not aware of any other code, except for triangle, that is not LGPL compatible.

But that is not the main issue. I would like to have seen this further discussed as there more related questions. Namely, how were the Win binaries built? With or without Shewchuck's code?

With Shewchuck's code: set (LICENSE_RESTRICTED off)

Another issue with that installer is that the GMT5_SHAREDIR env variable is appended to any existing instead of replacing. We cannot do that. because the later will be ignored (I think).

I would remove the variable entirely from the default windows environment and let startup_win.bat set GMT_SHAREDIR instead. This is already implemented and works with multiple parallel GMT5 installations.

Also the default installation dir proposed to the user should be the same that we have practise before "C:/programs/gmt5" instead of one that is revision number dependent.

I like to have multiple versions installed at the same time so that I can switch back if there is a bug. Adding the revision number to the path makes a clear distinction possible. If you don't like it think about this: deleting .0.0 from the full revisions path is easier than manually adding it.

RE: Enforce GPL or LGPL conformity - Added by Joaquim over 5 years ago

I would remove the variable entirely from the default windows environment and let startup_win.bat set GMT_SHAREDIR instead. This is already implemented and works with multiple parallel GMT5 installations.

We talked about it before. I am STRONGLY against that option. For example I need that variable in Mirone to detect if GMT is installed and to know where the coastlines are located. I also generate GMT scripts automatically that the user only need a double click on the batch file to run the script. This mechanism would be broken if GMT had to started each time by running the startup_win.bat.

Also the default installation dir proposed to the user should be the same that we have practise before "C:/programs/gmt5" instead of one that is revision number dependent.

I like to have multiple versions installed at the same time so that I can switch back if there is a bug. Adding the revision number to the path makes a clear distinction possible. If you don't like it think about this: deleting .0.0 from the full revisions path is easier than manually adding it.

We are not doing this for ourselves. I also have several versions installed and switch back and forth between them. Everyone that wants to have more than one version VOLUNTARILY can easily add its own naming schema but the regular user just wants to update and not worry/be aware with multiple installations. That is how it has been all these years and I don't see any good reason to change it.

RE: Enforce GPL or LGPL conformity - Added by Florian over 5 years ago

I would remove the variable entirely from the default windows environment and let startup_win.bat set GMT_SHAREDIR instead. This is already implemented and works with multiple parallel GMT5 installations.

We talked about it before. I am STRONGLY against that option. For example I need that variable in Mirone to detect if GMT is installed and to know where the coastlines are located. I also generate GMT scripts automatically that the user only need a double click on the batch file to run the script. This mechanism would be broken if GMT had to started each time by running the startup_win.bat.

The way it is now, GMT works without setting the environment via startup_win.bat. However, I agree you have no real control over what is stored in GMT5_SHAREDIR. Anyway, this whole concept is flawed. GMT should be able to guess the location of the sharedir on windows based on the location of the executable. It is quite simple: <execdir>../share. This should obsolete any further discussions.

Also the default installation dir proposed to the user should be the same that we have practise before "C:/programs/gmt5" instead of one that is revision number dependent.

I like to have multiple versions installed at the same time so that I can switch back if there is a bug. Adding the revision number to the path makes a clear distinction possible. If you don't like it think about this: deleting .0.0 from the full revisions path is easier than manually adding it.

We are not doing this for ourselves. I also have several versions installed and switch back and forth between them. Everyone that wants to have more than one version VOLUNTARILY can easily add its own naming schema but the regular user just wants to update and not worry/be aware with multiple installations. That is how it has been all these years and I don't see any good reason to change it.

OK, you can configure NSIS install path in cmake/dist/CMakeLists.txt

RE: Enforce GPL or LGPL conformity - Added by Joaquim over 5 years ago

OK, you can configure NSIS install path in cmake/dist/CMakeLists.txt

It seams I am having difficulties in passing my message. This not about what I can do but about what GMT will propose to their users.

RE: Enforce GPL or LGPL conformity - Added by Florian over 5 years ago

OK, you can configure NSIS install path in cmake/dist/CMakeLists.txt

It seams I am having difficulties in passing my message. This not about what I can do but about what GMT will propose to their users.

I got it. Sorry, I was just not clear in my response: Could you please do the necessary edits in cmake/dist/CMakeLists.txt so that they meet the user's expectations?

RE: Enforce GPL or LGPL conformity - Added by Florian over 5 years ago

Another issue with that installer is that the GMT5_SHAREDIR env variable is appended to any existing instead of replacing.

Could you have a look at cmake/modules/NSIS.template.in and search for ADD_TO_PATH_ALL_USERS? It seems to be possible to tweak this file so that variables are replaced instead of appending. I'll add an issue.

(1-8/8)