search

CsatiZoltan / CristalX

Identification and analysis of polycrystalline microstructures
https://cristalx.readthedocs.io
GNU Lesser General Public License v3.0
6 stars 7 forks source link

Licensing? #16

Closed CsatiZoltan closed 4 years ago

CsatiZoltan commented 4 years ago

This project was initialized with the MIT license. As I plan to use GPLv3 licensed code, the whole project will have to use either GPLv3 or a compatible license. More on the GPLv3 license: https://choosealicense.com/licenses/gpl-3.0/.

I am not sure about the implications of re-licensing this project. Will it make others more difficult to use my code?

CsatiZoltan commented 4 years ago

A major part of this project is carried out with PythonOCC, which is LGPLv3 licensed. One way to change the licence. That's what I will do for now. In the future, one could proceed with a dual-licensed solution: separate the PythonOCC code from the rest, and use LGPLv3 and MIT licenses, respectively. I see two possibilities about how to do the separation:

  1. Separate the code that uses PythonOCC into a distinct branch, while keeping the master branch free of PythonOCC code (or vice versa). This is inconvenient for me because currently I actively work on PythonOCC-related codes. Backporting parts of the code would need too much work and would be error-prone lacking a test suite. Once I more or less finish the PythonOCC codes, I could/should do the separation.
  2. Simply put all code that uses PythonOCC into its own module. However, I prefer to structure my code into modules based on logical units (geometry, visualization, etc.). PythonOCC-related code appears both in the geometry and in the visualization modules, so it contradicts my requirements. For such a relatively small project, I don't want to create a new package for the sake of separation. However, if the project becomes more complex, it might be useful to do this separation to have 
    grains
  |--- geometry
  |--- visualization
  |--- ...
pythonocc
  |--- geometry
  |--- visualization

    A third possibility, to use an alternative to PythonOCC, does not seem to be viable at this point. The spline approximation for curves can be done with many lightweight Python libraries but creating a STEP representation of the surface the splines encompass seems to be supported only by Open CASCADE (which PythonOCC wraps).