Permissive license or LGPL?

[ericpre]

Now that the IO code of hyperspy has been split, it may worth considering re-licensing the code with a more permissive license in RosettaSciIO.
I don't a strong view on this topic, but I start this discussion because it is coming up once in a while, and it seems that there is appetite for a more permissive license, as keeping the GPL license could prevent adoption by some libraries/softwares.

[vasole]

My preferred license for collaborative work is LGPL, particulary in the case of a library: You use it, but if you modify/improve it, you are forced to distribute the modifications.

However, that license was not appropriate for collaboration with some US scientists. Basically their caveats were that if they are paid by the US administration, the US administration must be able to use their code and that could be problematic (DoE, defense,...) even for the LGPL case.

Therefore we have adopted MIT in most projects (hdf5plugin, PyMca, silx, fabIO ...)

[sem-geologist]

I think LGPL also is very appropriate license

[sem-geologist]

There is other nice features of LGPL. Some of these works (like mine reverse engineering of formats) is to give freedom and save users or comrades-in-occupation (SEM and EPMA operators) from wasting unnecessarily time by thousand of mouse clicks normally required to achieve even basic functions... The usability for other interested parts (OEM, other software developers) is of secondary importance at least for me. Closing such library (or) parts is like undoing the effort of reverse engineering. So LGPL forces to leave such part open, and still gives the freedom to user to replace such library with newer version as LGPL allows only dynamic linking. So the User can use some proprietary software and use open source library with all benefits coming with it. We should remember that LGPL / GPL is to give user a freedom, not to empower some third part OEM. And LGPL I think is this kind of compromise to let it be useful with proprietary software and still maintain huge degree of freedoms for user.

BTW, I can't understand what's the problem of DoE defence... Somehow Linux being GPL (mostly RedHat) and running on their War machines going to Iraq was not at all a problem (At least I saw some articles there and here claiming that). What had changed in USA administration/military to get against GPL?

[vasole]

Please, do not misunderstand me. If I would have a vote, it would be for LGPL.

| What had changed in USA administration/military to get against GPL?

No idea. May be they do not want to get suited because of not distributing their code?

I work for an European research organization and our general software policy is to give access to our developments to the whole community and not only to the countries belonging to the organization.

[francisco-dlp]

I agree that LGPL is a more appropriate license for RosettaSciIO (and possibly for HyperSpy too). While it doesn't maximise the potential users of the library (for that we'll have to think on BSD or similar), it increases substantially its domain of application without compromising on the essential: any modifications to the library must be published under the same terms.

[sem-geologist]

One thing what most of different kind of end users does not understand (including mentioned administrations) that no one needs to distribute changes or switch its code base to GPL then using GPL parts - unless they are distributing it for third parties (selling, or giving away attached as a single product). So if DoD (or any other agency) needs own modifications - and for sure they are not going to use those outside from institutions - who ever is going to find out and sue them? The Law which can't be anyhow enforced is a dead law. In my view, Technically I see very little difference between commercial products requiring third part GPL libraries, LGPL libraries or comercial libraries. What is the difference between application which requires on MS Windows to get and install some .NET runtime compared to app on linux which for functioning needs to get PyQt5 or PySide6, gnuplot, libpng and so on... No difference. The difference is when distributing fully functioning products with all necessary libraries included - and this is where these Licenses are relevant. There are some purists which would want only GPL everything and try to bend the reality to make us believe that we can't mix different licenses (well developers can't, but that is not end users!).

[sem-geologist]

an example: pyqtgraph library is licensed under BSD. Wait a moment, but PyQt5 requires either GPL or commercial! Yeah, but pyqtgraph does not modify the PyQt5 and is not distributing the PyQt5 - which is left to get installed for end users or developers.

[vasole]

| - and for sure they are not going to use those outside from institutions -

They are selling/distributing things to other countries too.

| The Law which can't be anyhow enforced is a dead law.

That's true.

However, I think we are digressing from the discussion (probably my fault)

I'm a developer, not a user :-) and I am already giving away my source code. However my code is also be used as a library by other developers and I do not want to impose a license to them. I look forward to see SFS code released under LGPL (or something similar). If it is the whole RosettaSciIO, it is even better.

My own code is licensed under MIT.
When I ship a frozen binary, the license of the frozen binary is GPL if I use PyQt5 and it is MIT if I use PySide2/PySide6.
For the time being, the simplest I can do is to add your code to the frozen binaries (adding the whole HyperSpy would introduce too many additional dependencies).

[francisco-dlp]

It is not that simple: @sem-geologist's code has being edited by a number of other developers. To distribute the code under a different license that is compatible with your needs we need to ask all the contributors to agree changing the license of the files.

I suggest that, if we are going to go through such a process, let's do it first for the whole repository. If issues arise, then we can considering re-licensing just parts of the code. Does it sound good?

[vasole]

It is not that simple: @sem-geologist's code has being edited by a number of other developers.

But not his very first version:

hyperspy/hyperspy@c198833

To distribute the code under a different license that is compatible with your needs we need to ask all the contributors to agree
changing the license of the files.

For the current status of the code, yes.

[sem-geologist]

@vasole tell my why You are so much interested in SFS? SFS is only the first layer (think about it like zip file). SFS allows to extract internal files - it is indeed useful on its own for developing anything else handling Esprit data. i.e. .pan files (where every tile has its own xml file) and EBSD bcf are packed into such SFS containers too. Initially the sfs code was in separate file, but later I had bunched it into same file to make no mess in hyperspy source file hierarchy. Now, as this library is getting the shape I think it would be good idea (independent from the license change or not) to split that code into separate files as it was initially intended as that will improve maintainability.

[vasole]

Because I already have tools to parse Bruker XRF files (for instance rtx files). What I need is access to the internal files of the SFS container to handle the bcf case.

[sem-geologist]

rtx is a different beast! it is (XML based) project file. You still will need binary parser, SFS alone is not enough. Actually the XRF-EDS bcf and SEM-EDS bcf has the same amount of internal files inside sfs container with same file names. The only difference is the Header file (inside SFS container) which for XRF would contain additional nodes describing the X-ray properties, where sample and detector description would be identical to SEM-EDS. Most important binary Cube (which needs lots of decoding and there is this fancy cython code included to parse it really fast) structure is absolutely agnostic if that is electron excited EDS or X-ray excited EDS hyperspectra. You are not first asking for handling XRF (see this #19) and after solving the #37 maybe it finally can be progressed further (albeit I have no µ-XRF hardware thus it is hard for me to implement it.). But I think You could be useful here as looks You are already familiar what is needed to be read from XML. the Header (XML) file in the SFS container will contain very similar XML nodes as You are familiar already in rtx.

[vasole]

By inspecting the file I thought it was just XML embedded in a SFS container and therefore I already had support for the content as I wrote in #50

[AlexHenderson]

Personally, I think LGPL is the most restrictive licence that should be applied. My MATLAB toolbox (I know, I know. That was then, but this is now) was licenced GPL, and now I can't change it without throwing out lots of GPL licenced packages I've incorporated. Indeed, I was looking for a Python parser for Renishaw Raman files and came across one licenced GPL. When I asked if they would consider switching to a MIT licence, it turned out they'd modelled their code on my MATLAB version which was GPL. D'oh! We both decided to scale back to MIT for that code, which makes my Python toolkit more attractive.

In the FAIR data community they say "as open as possible, but as restricted as necessary". What would we say are necessary restrictions? Acknowlegement of original authorship? Requirement that distributed, modified versions are released? Any others? Then determine a licence based on that minimum set.

For the record, I'm now using MIT.

[vasole]

But I think You could be useful here as looks You are already familiar what is needed to be read from XML. the Header (XML) > file in the SFS container will contain very similar XML nodes as You are familiar already in rtx.

I do not have the equipment. I just provide the analysis software :-)

To be able to load the data, one effectively needs the patch suggested in hyperspy/hyperspy#2898 concerning self.hv

However, that is not enough with huge maps (the only one I have is 1273 x 1578 x 4096). If I do not down-sample the data, the data type is wrongly interpreted as uint8 (instead of uint16).

Did anybody encountered that problem already?

[vasole]

@sem-geologist hyperspy/hyperspy#3048 submitted.

[jlaehne]

This discussion has somewhat stalled (and partly deviated). Still, I think it would be good to go about the re-licensing now that we are close to an initial release - even if might only be implemented in a follow-up release. In principle, we had several proposals for different alternative licenses:

• At least, we should move to LGPL to be more permissive (and there seems to pretty much a consensus on that)
• For even wider adoption, MIT (or BSD) might be more suited option(s), but remove the requirement to publish any modifications to the library under the same terms

So as step forward, we should

1. Decide on the licence we aim for (in the next weeks)
2. Try to get agreement from all Contributors (there are 38 in total, do we need agreement even from people who have only corrected typos? Any idea how to best get their agreement?)
3. Publish individual readers under separate licenses if we do not get the agreement of everyone