Reliscensing .mrc file Loader

[CSSFrancis]

Maybe it is about time to think about reliscencing some code bit by bit.

LiberTEM is planning on re-licensing to a more premissive license: LiberTEM/LiberTEM#1649

Currently some of the .mrc file loading is broken in LiberTEM and it might be nice to just have a single file loader to support rather than supporting multiple different versions of the same thing.

Describe the functionality you would like to see.

@sk1p Maybe you can better explain what license you would need to refactor? But my understanding is that LGPL should be sufficient? Otherwise we could maybe consider MIT?

Describe the context

Just pining the people who have contributed to the .mrc file loader:

@ericpre @jlaehne @francisco-dlp

[CSSFrancis]

Also @pietsjoh 😅

[sk1p]

See also #51 for the general question

[sk1p]

Maybe you can better explain what license you would need to refactor? But my understanding is that LGPL should be sufficient? Otherwise we could maybe consider MIT?

I would be most happy with the MIT, because that would match what we are already using for our I/O code, so that would be a no-brainer. It's also a bit easier to understand than LGPL, and has less requirements for re-use.

Of course, this is only my perspective, and reading #51 again there are others that prefer the LGPL (which is the classic permissive vs. copyleft thing), so probably there needs to be some kind of consensus forming process.

How would you propose to re-license things bit-by-bit?

[ericpre]

The "bit by bit" re-licencing may be messy in term of distribution (make separate package) and getting approval to change from all contributors will take some time.

@CSSFrancis, if you think that it would be beneficial to change the license of the MRC reader in a shorter timeframe than re-licensing the whole of rosettasciio, then one option would be to include the MRC code where it is needed. Maybe this could be done by as simple copy and paste while keeping the rosettasciio as upstream or doing some git wizardery involving submodule and filter-branch...

In term of license, my view is that a more permissive license will be the simplest because it seems that there are ambiguities around the use of LGPL.

[jlaehne]

I would not object to a reliscensing or either a part or the full package. The biggest hurdle seemed to clarify what the best choice of license is, but as far as I remember a number of points were indeed pointing towards MIT being the best choice.

It might though be hard to get explicit consent from all contributors as some might not be active on github any longer. I currently have no idea what the best way forward would be on that.