License incompatible with target core library license?

[IAlibay]

I think? LGPLv3 means that we can't keep this as a core dependency of MDAnalysis and also aim for LGPLv2.1.

[IAlibay]

I'll be honest this is one of those where I'm not 100% sure because allegedly importing is not derivative work - so technically the license choice shouldn't be affected. I think we might need to kick this back to NF for clarification at some point.

[orbeckst]

I don't think it matters: My understanding is that GridDataFormat's LGPLv3 allows making use of the API from any code and importing into any code, regardless of the calling code's license: it could be LGPLv2.1 or "sign-in-blood-here-LICENSE".

Ideally we'd have the same license in MDA core and GDF but I don't think it's a show stopper or requires us to remove it as a core dep.

[orbeckst]

(Ultimately, wasn't this the whole point of relicensing MDAnalysis?)

[IAlibay]

@orbeckst the issue here is about how combined works happen - the Apache 2.0 issue is related to this (inherently Apache 2.0 allows you to choose whatever license you want but isn't compatible as a combined work).

I think it's still fine but I need some time to find my notes and think about it.

[orbeckst]

Ok, more complicated than my admittedly naive understanding of licensing. Lawyer territory ;-).

[IAlibay]

This is a glaring hole in the discussion with Pam I'm afraid, the last bit I can find is the following statement from me:

"LGPLv2.1-only would relicense to GPLv3 when combined with LGPLv3+"

It's unclear if the combined work of an LGPLv2.1+ licensed code importing a LGPLv3+ licensed code wouldn't lead to a an overall LGPLv3+ package. The rationale here is that the terms of the LGPL (at least accoridng to my interpretation of the FSF) are that you can relicense to GPL, and GPL needs all it touches (either through import or otherwise) as needing to be compatible with its license.

This might be one we have to throw back to Pam, thoughts?