Switching from GPL 3 to BSD 3 License

[argerlt]

What are people's thoughts on switching from the GPL 3 license to a more liberal BSD license, such as what is in scipy?

In my research, I work a lot with the United States Air Force, as well as NSF-funded university projects. In both cases, the end goal is to create technology that everyone can use, both commercially and in academia. As such, my collaborators often refer to Orix as a "ticking legal time bomb", and pretty much guarantees our industry partners will refuse to work with us on projects utilizing Orix.

Obviously I am not a lawyer, this is not legal advice, and changing a license is not something to be taken lightly, but switching to a BSD 3 Like this one from scipy would significantly broaden the projects I would be allowed to incorporate Orix into.

Case in point: HEXRD is a fantastic tool for studying far field synchrotron data, and is the de-facto program used at several of the CHESS beamlines, and also sees heavy use by some users at APS. It's handling of orientations would benefit from an update, and I would like to use Orix for this purpose. However, the GPL license makes this a non-starter for the HEXRD team, so I am instead forced to make my contributions using scipy Rotations, which are slower lack the functionality of Orix quaternion objects.

[pc494]

Personally I feel (fairly strongly) that the infectious property of GPL-3 is part of the appeal. I can't presume to speak for the politics of other contributors though.

[argerlt]

Personally I feel (fairly strongly) that the infectious property of GPL-3 is part of the appeal. I can't presume to speak for the politics of other contributors though.

@pc494 Could you elaborate a bit on what you see as the advantage of this infection ? I've been pretty heavily indoctrinated into the the pro-BSL camp, but it sounds like you made the choice of GSL intentionally. Feel free to link me to a good online resource too.

[pc494]

GPL is infectious in the sense that if a project is using GPL code, and then decides it wants to distribute it must distributed under GPL. This prevents proprietary code (which someone has presumably paid for, either via labour or with a direct transaction) from cherry picking GPL code to supplement an existing product/service that they sell/distribute while withholding source.

In contrast, BSD (or similar) allows a closed source code to subsume open source code - which I consider undesirable.

Broadly, I think discussing this in the abstract is rather difficult, feel free to email the team with a more detailed account of what your partners are likely to want (assuming this information is somewhat privileged and thus not fit for a public fora).

[pc494]

Thanks for converting to discussion @hakonanes - I should have remembered we had this.

[hakonanes]

Hi Austin and Phillip! Thanks for bringing this up.

In short: I'm in favor of a more permissive license. But, parts of orix' functionality are adapted from MTEX, which has a GPLv2 license. This means that orix in its entirety cannot have a BSD license. However, without splitting the repository or adding other undue maintenance costs, we can try to release an orix[base] (or similar) package with a BSD license, without the parts adapted from MTEX. Nothing should change for the regular orix end user. What do you think of this idea @pc494, @harripj, @dnjohnstone?

---

My motivation for a more permissive license is to enable use of orix in PyEBSDIndex to support fast Hough indexing of EBSD patterns from more than FCC/BCC materials, which would use functionality in symmetry.py, mostly. PyEBSDIndex is written by Dave Rowenhorst, who works for the US Naval Research Laboratory, so the software has a custom permissive license, incompatible with GPL.

it sounds like you made the choice of GSL intentionally

orix came out of pyxem which came out of HyperSpy. Both pyxem and HyperSpy are GPLd. I believe this is the main reason for orix being GPLd as well.

I don't know how much of other's additions to orix' functionality is adapted from MTEX. Ben (original committer) wrote "heavily inspired by MTEX" in the README, but to what extent I'm not sure. Could you enlighten us here, @pc494? My additions adapted from MTEX are clearly marked as such, with "Adapted from MTEX" in the docstrings or comments. These are mostly the IPF functionality added last year, and includes restricting the stereographic projection to fundamental sectors based on symmetry and coloring orientations (from directions in IPF or Euler angles) and crystal directions (in IPF). This functionality (and more) would be unavailable in a BSD version of orix.

What must be done before we can release orix[base] with a BSD license? All our dependencies (listed in install_requires in setup.py) have BSD compatible licenses: BSD-2 (matplotlib-scalebar, numba), BSD-3 (dask, diffpy.structure [I interpret their license as BSD-like], h5py, matplotlib, numpy, pooch, scipy) and MIT (numpy-quaternion, tqdm). No issue there. We can reimplement the functionality adapted from MTEX using a BSD compatible source, but I don't want to do that. So, the only solution I can think of is for this functionality to be separated out into their own files, and then make them unavailable in some way when packaging orix[base]. We can raise a custom error whenever functionality not available in orix[base] is called.

Take the fundamental_sector attribute of the Symmetry class e.g., which defines the IPF sectors for the Laue groups: We can separate out that code in its own file with a GPLv3 notice and only make it available if some requirement is met upon installation. Whenever new functionality is added which must be GPLd, they can be implemented in these GPLd files and not be available when people install orix[base]. I do not know at the moment how to handle this requirement upon installation, though.

---

Below I've listed all modules and marked functionality I believe must be GPLd: "*" signifies that parts of a module or file must be GPLd, while "^" signifies functionality adapted from MTEX. Functionality not listed within a module I consider OK to relicense.

• base
• crystal_map
• data
• io
• plot*:
  • direction_color_keys^
  • orientation_color_keys^
  • inverse_pole_figure_plot* (uses Symmetry.fundamental_sector^)
  • stereographic_plot*:
    • restrict_to_sector (uses FundamentalSector^)
• projections
• quaternion*:
  • orientation*:
    • in_euler_fundamental_region^ (uses Symmetry._special_rotation)
  • symmetry*:
    • fundamental_sector^
    • _special_rotation^
• sampling
• vector*:
  • fundamental_sector^
  • miller*:
    • in_fundamental_sector^
    • round^
  • vector3d*
    • in_fundamental_sector^

[hakonanes]

Quoting myself:

We can reimplement the functionality adapted from MTEX using a BSD compatible source, but I don't want to do that.

EMsoft, which has a BSD-like license, has an IPF coloring module, which we could replace parts of the MTEX adapted code with. This will not however remove the need for FundamentalSector in Vector3d.in_fundamental_sector(), because the EMsoft code supports Laue fundamental sectors only.