license for DINA modules

[kcranston]

The current licensing guideline is quite vague, allowing for any open source license but with a preference for one that is 'bigger and more well-known and frequently used'.

I would prefer that the TC pick one license for official DINA modules, making it simpler for distribution and re-use of the DINA system. My vote would be non-copyleft, and specifically MIT, but I would like to hear opinions from other members of the TC.

Tagging some TC members, but do ping others in your organization. @gnewton @cgendreau @falkogloeckler @Inkimar @idali0226

[gnewton]

MIT license would be best. The Government of Canada Treasury Board is using the MIT license, so all of our (AAFC) code also uses this.
Having a single license across all modules would simplify legal and some technical issues.

[gnewton]

I believe this should be added to the MOU: If you want to participate in DINA, you need to Open Source your contributed code using the MIT license.

[falkogloeckler]

Would the usage of MIT license affect the choice, re-use and potential distribution of existing "external" code (e.g. libraries) that use open licenses other than MIT?
If there are conflicts, we might want to recommend workflows on how to include such code (e.g. download during deployment instead of re-distribution).

[mikkohei13]

I agree that MIT would be a good choice, making licensing easier to understand and allowing wider use of DINA modules, than more restrictive and/or rare licenses like the AGPL (Affero) that has been used so far at NRM.

It would also make communication easier if all modules would share the same license. MIT also seems to be overwhelmingly the most popular open-source license currently.

@falkogloeckler I'm not an expert on this, but I think it would not affect. When we use a third-party tools, we are bound by their license anyway, regardless of our licence choices.