add a few valid dependency cases

[nilshamerlinck]

disclaimer: I'm not a lawyer :)

based on Odoo's licenses:

• LGPL-3/MIT module can depend on OEEL-1/OPL-1 module

also MIT module can depend on LGPL-3 module (but not on Apache module; removed Apache from the comment to avoid ambiguity; wasn't taken into account anyway)

[sbidoul]

Thanks. Would you mind adding a news fragment (58.feature - or is it a bugfix?) and a couple of test cases to reproduce the problem this fixes?

[ng-ife]

I addressed the issues in #74 . @sbidoul Do you mind having a look?

[sbidoul]

Thanks @ng-ife

Looking at this again, I have a concern. Imagine

• A: AGPL
• B: LGPL
• C: proprietary
  With A depending on B and B depending on C.

Before this change, B depending on C will be flagged.

With this change, B can depend on C. But then A (AGPL) depends on B, which depends on a proprietary module, so that is not ok?

Or do I miss something?

[ng-ife]

@sbidoul Thanks for your feedback.
Situation seems to be a bit tricky. (As indicated here.
Following this argumentation I would say A based on B should already be invalid.

What do you think?

[sbidoul]

Following this argumentation I would say A based on B should already be invalid.

I think AGPL can depend on LGPL, that is fine.
LGPL depending on AGPL is problematic, IMO, as it "hides" a less permissive license.

[ng-ife]

Thanks @sbidoul for clarification. This way it really seems to be impossible to open source code that is based on proprietary software (in this case Odoo EE modules). This is to bad but I get the point. Will close #74 then.

[sbidoul]

I'm not saying I have the definitive answer :) It's a complex matter.

It might make sense to have open source that depends on proprietary, but if we allow it in manifestoo, we'll probably need a more sophisticated algorithm to detect transitive incompatibilities.

[sbidoul]

MIT module can depend on LGPL-3 module (but not on Apache

@nilshamerlinck out of curiosity, do you have a reference about MIT/Apache compatibility ?