Further discussion on license mixing with other open source projects

Hi all,

I made a commitment to do some due diligence as it relates to the OpenMRS community’s ability to incorporate content that is registered under licenses different than the MPL 2.0 - HD. My due diligence comes from some of my own research, alongside a fairly lengthy conversation with @lrosen. For those of you who aren’t aware, @lrosen is a lawyer deep with open source expertise, the author of a book called “Open Source Licenses”, and a friend to the OpenMRS community.

I’ve encouraged him to correct what I’ve written below, but I asked to write this note, to ensure I understand what he’s tried to teach me. :slightly_smiling:

For context, I’d like to point people to the following documents, which are good “pre-reads”:

The current OpenMRS Contribution Policy: https://wiki.openmrs.org/x/noAGB The current OpenMRS Copyright Policy: https://wiki.openmrs.org/x/RoP7Aw

The first and foremost distinction to make about licensing is to understand the distinction between licenses that are placed upon a given source code file, and a license that applies to a software composition.

The OpenMRS community, when working together, defaults to applying the MPL 2.0 with HD to all newly created source code files, and all historical files also carry that license designation. All of these files are copyrighted to OpenMRS, Inc… which simply ensures that the broader community of end-users is held to the standards our contributors expect (as described in the MPL 2.0 license).

When we come together as a community to create a bundling of source code… and compile it into one or more executables, we license that composition under the MPL 2.0 HD as well.

Now… let’s say for example that we want to include a new piece of source code into an anticipated composition, called OpenMRS 4.10. That source code could be copyrighted to a different and distinct holder from OpenMRS, Inc., and it can also be licensed under a different open source license. We then have the legal right to license that composition (which includes the source code from a different copyright holder) underneath the MPL 2.0 HD license.

According to our copyright policy:

OpenMRS Inc. and the OpenMRS community respect all copyrights and copyright licenses. Individual components of OpenMRS software and documentation may also be available to the public under the open licenses chosen by their copyright holders. We disclose information about those components and their licenses in the NOTICE file that accompanies our software.

So, through the use of our NOTICE file, we can disclose those copyright holders, alongside the license expectations that come alongside that source code.

We could also potentially go a step further, and ask the original copyright holder for a license to release some specific set of source code files under the MPL 2.0 HD.

Both of these strategies are ways to ad-mix licenses from separate sources of intellectual property.

If, in the event that a 3rd party misuses that newly incorporated source code, the OpenMRS community and OpenMRS, Inc. would not be responsible for the implications of that breach. Our copyright policy and contribution policy, alongside the additional steps of a NOTICE file declaration make it clear that downstream users carry the responsibility to appropriately use the products we produce.

I hope that makes sense.

2 Likes

Paul, what was not exactly clear was what happens when those incorporated licensed-bits are more restrictive than the MPL 2.0 license? Does the entire composition require the more strict interpretation, or just the little bits? And if just the little bits, is that practical/pragmatic?

From what I’ve been told, the “composer” has the authority to declare the license of the composition, and that’s independent from the license of the source code files that make up that composition.

Part of the interesting aspect of all of this, is that different lawyers have different interpretations of the implications of a 3rd party breach (i.e. someone downloads OpenMRS 4.5 and breaches the expectations of a different copyright holder). The truth of the matter is, these circumstances have never been tested in a court battle. That is why I wrote about the ways to further mitigate risk and misunderstanding.

One way is to straight up declare that the composers are aware of incorporated code’s copyright holders wishes, by documenting them in the NOTICE file. That puts the burden on the user to be aware of the implications of what they are using.

A good example of how another project does that is here: https://github.com/apache/spark/blob/master/NOTICE

Another way is to go another step and formally request to license code copyrighted to a different holder under our intended license: “i.e., hey Eclipse Foundation, can I please use x, y, and z source components inside OpenMRS 4.3 and license them under the MPL 2.0?”

Hope this clarifies.

This makes sense, and it tracks with my IANAL reading of AGPL, but I think it’s tangential to the actual question at hand.

The thought question that someone asked in Singapore was: what if the OpenMRS community wanted to take 90% of the Bahmni codebase (which is AGPLv3), modify it (e.g. to make it more generic), and then release this as the basis of Reference Application 3.0.

In that case, OpenMRS would be releasing a modified version of AGPL source, bundled with some MPL source (openmrs-core and module). I don’t know if we could declare that the aggregate is MPL or not, but regardless of that, the most visible part of the release, the actual application, and the thing that someone would need to fork and modify if they want to go their own way, would be AGPL.

The two parallel question are:

  1. Would this be a deal-breaker to OpenMRS? (i.e. are we committed to MPL and thus would refuse to base a release on code that substantially requires users to accept a viral FOSS license?)
  2. Would ThoughtWorks be willing to re-license Bahmni as MPL?

To the second question, ThoughtWorks’s lawyer for the Global Health team (who helped choose the AGPL license in the first place) would want to talk about this in more depth by voice to understand what we’re asking and why. He’s generally available for the first 30 minute of our leadership call slot (though not tomorrow).

So, perhaps once we understand what we think about #1, we could invite him to join us.

1 Like

Couldn’t we get the Bahmni team to say, “Yes, you may release it under MPL” – the maintainers are allowed to say you can relicense…but I’d get that in writing for legal reasons. I cannot see a reason they’d say “No” no us.

[Removed. Sent correctly below.]

I want to reply to Paul’s original email and the above responses by describing it all in my own words. Is this easier to understand? /Larry

The OpenMRS Contribution Policy allows our OpenMRS software distributions to contain contributions from among the entire open source universe. Software that is free for us to copy, free for our community to modify, and free for us to distribute in both source and binary forms, is perfect for our goals regardless of which open source license it is under. That is the advantage of having a consistent interpretation, primarily by Open Source Initiative but also by others, of what it means to be a “certified” open source license for software that meets the Open Source Definition.

The OpenMRS Contribution Policy also requires us to honor and to obey the original license terms applied by the original authors of those valuable contributions. Nothing in any open source license allows OpenMRS to change the licenses for any software contributed to us.

We caution everyone: That is why we publish a list of all contributions – and their open source licenses – in our NOTICE files.

As an aggregator and distributor of these software contributions in OpenMRS applications, our OpenMRS community is committed always to licensing our own collective software aggregations under the MPL-HD license. This is not difficult. All we have to do for our own distributions is to make sure that all contributions to us that we redistribute are under one or more of those certified open source licenses. All those licenses provide us with the freedom to copy, the freedom to create derivative works, and the freedom to distribute both source and binary forms of our software. We have all the rights we need to distribute our open source software aggregations with those contributions.

This is the way our community interprets the ownership and licensing effect of our aggregating independent open source copyrighted works. Our community owns the aggregations, not the individual contributions.

Those original licenses that the authors applied to their original contributions are not done away with merely by our aggregating those contributions. Every organization that itself distributes or modifies OpenMRS applications should read those NOTICE files. In particular, do not yourself modify OpenMRS contributions without obeying the terms and conditions of their individual licenses.

If we were simply talking about aggregating/combining source from different projects into one, what’s been described sounds fine.

Darius alludes to the fact that we’re not simply combing files side-by-side; rather, we’re talking about putting MPLv2-licensed source from the OpenMRS community and AGPLv3-licensed code from Bahmni into a repository and then making revisions across all of them to produce something new. Metaphorically speaking, we’re not talking about putting Honeycrisp and Gala apples into a single basket. We’re talking about taking Honeycrisp & Gala apples, grinding them up, and making delicious apple sauce with them.

Making apple sauce is unfortunately the creation of a derivative work under copyright law, which requires the consent of the owner of the MPLv2 code and the owner of the AGPLv3 code. I didn’t create that law, although I exaggerate its application to apple sauce.

I actually believe that programming is much more subtle and professional than “grinding components up.” And for two or more open source communities to fail to agree to some compromise inter-project licensing and refuse to work together on an important shared derivative work project, shame on them.

Add one more reason why this doesn’t matter. Concede to the AGPLv3 community. If that license is important to them, let the derivative work of that component be under the AGPLv3. That isn’t difficult, although it may spoil your moral mood for the day.

In any event the entire OpenMRS aggregation goes out under MPL-HD.

Let me try to be disgustingly precise here. Your word “we” means “OpenMRS Inc.”

We is not any other individual or company contributor. We only aggregate/combine source code from other individual or company contributors. We don’t write software. We generally trust our contributors.

That is one advantage of our legal form of corporation. Be grateful for those corporate liability protections.

What those individual or company contributors did will be described in the DAMNED NOTICE file. (Perhaps if we change its name slightly people will read those warnings. :grinning: )

Also trying to be very precise:

@lrosen , to confirm, if the OpenMRS community were to produce the following aggregation of different code repositories, and release this as OpenMRS 7.5:

  1. OpenMRS Core (which is MPL-HD)
  2. various OpenMRS modules (all MPL-HD)
  3. a fork + modifications of the Bahmni user interface (which is AGPLv3)
  • and further development would keep happening in this code

…then component #3 and its further modifications would remain AGPLv3, though the whole aggregation (e.g. any documentation or scripting tying the whole thing together) could be MPL-HD.

Particularly, if some OpenMRS developer were to take this aggregation, and modify the patient dashboard screen in component #3, then they must share that modification as AGPLv3

Is that right?

1 Like

Yes. /Larry

Okay, so given that, I think the relevant questions are what I wrote above:

Please don’t use the word “viral” to describe this situation. Just as there is nothing we can do to force-change their license from AGPLv3 to MPL-HD, neither can they force-change anyone else’s license for other independent contributions into AGPLv3.

So long as your description of professional software development below is accurate, (and you are not simply creating apple sauce or grinding components together), nothing AGPLv3-viral affects parts 1 and 2, or the MPL-HD aggregation as a whole.

Everyone downstream can use these OpenMRS aggregations for free.

What downstream redistributors of OpenMRS aggregations must do is to republish our existing NOTICE file to their own customers. That is their own compliance with AGPLv3 and MPL-HD and any other open source licenses for components in our aggregations. Because of the possibility that AGPLv3 will affect their form of network distribution to third parties, downstream redistributors should carefully read that NOTICE file. [But please don’t call that a “viral” affect. There are lots of such unique requirements in all open source licenses – including MPL-HD – regarding attribution, patents, and reciprocity that must also be described in the NOTICE file and accepted.]

Also, downstream modifiers of any component must comply with AGPLv3 for their changes to that component, and with MPL-HD for those components, and with the license conditions for any components they actually change. And they must update their own NOTICE file to describe their modifications.

There is a group of attorneys and others working at the Linux Foundation to define a standard XML-format (“SPDX”) for much of this NOTICE information. Stand by…

If I understand correctly, I think the overall question that Darius is getting at is that if, say, “the OpenMRS 7.5 Reference App” contains a UI that is AGPLv3, then could a third-party take “the OpenMRS 7.5 Reference App” as a whole and make a derivative/custom distribution that they copyright and sell (which, if I understand correctly, they could do if it was all MPL-HD)? And if the answer is no, do we care about that?

Mark

Selling has nothing to do with it. Anyone can sell open source software or, as in my case, sell services relating thereto. (It is usually not as expensive as the proprietary equivalent.) Anyone can sell (i.e., redistribute) OpenMRS applications and all its open source components, including our NOTICE file, at any price or free.

Make a derivative of what? And who owns what? Quoting 17 U.S.C. 103(b):

The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.

So if you identify an AGPLv3 (or MPL-HD) component of which someone has made a derivative work, that derivative work remains under that component’s AGPLv3 (or MPL-HD) copyleft license. And remains free open source for anyone to use. Including us again in OpenMRS! All copyleft open source licenses work that way.

And we – this OpenMRS community – control what we distribute in our own trademarked OpenMRS aggregations under MPL-HD.

Let me try to state this again, more precisely, and without the word “viral”. Because I think that the licensing is clear, it’s just an open question how the OpenMRS community would want to behave in a particular situation.

  1. Someone suggested that we create an aggregation which has an AGPLv3 user interface (forked from Bahmni) and an MPL-HD backend (OpenMRS core and modules)
  2. If the OpenMRS community builds and releases this aggregation, that means releasing a product for which modifying the user interface would be subject to AGPLv3.
  3. So the question (not a legal one, but a political one) is: would we (the OpenMRS community) want to do this? Would we release an aggregate distribution in which one significant component (that we expect others would want to derive from) has a strong copyleft AGPLv3 license?

I feel like this question is perfectly clear (though the answer isn’t obvious), but it must not be as clear as I think it is…


I don’t know what the answer to that should be.

It’s worth saying that the original rationale for OpenMRS not choosing a Strong Copyleft license like AGPL was that we wanted to allow anyone (including for-profit companies) more freedom to extend OpenMRS (including with proprietary code). We figured this might lead to more overall contributions in the OpenMRS ecosystem. Over the course of this decade I don’t think we’ve seen much of this activity.

What we’re seeing here is that a for-profit company has actually built a UI on top of the OpenMRS platform, and done so with a stronger copyleft license, rather than a proprietary one. Which is basically the opposite of the situation we considered a decade ago.

@darius, that is a much better phrased political question. :grinning: A question that I, as a lawyer, should not pretend to have a better answer than you. This isn’t a legal response, therefore, merely my individual political one, to this question:

Why not? The only notable difference between our interpretations of the AGPLv3 and the MPL-HD licenses is the AGPLv3 extension of “distribution” to include “network distribution to third parties.” Every other difference between these two copyleft licenses is only in the details seen by microscopic lawyers and has nothing material to do with its strength or weakness as a copyleft license.

Nothing in the AGPLv3 obligates us or anyone else to convert other licenses for other independent components of OpenMRS to AGPLv3. There is no viral infection by us, because we (“OpenMRS”) merely aggregate the contributions of others. But we are thorough. We expect our contributors to be professionals and not create apple sauce for your patients to consume.

But conflict among open source license communities over “strong vs. weak” copyleft continues. Even though that “critical distinction” makes as much sense to me as strong vs. weak medical care, I understand why this is a political question here. Good luck answering it in a way that creates the most free medical software for the entire world.

Based on what people told me at the time, I understood MPL allowed for openmrs-core to be copyleft, but for people to write proprietary add-on modules. And that GPL wouldn’t allow this.

Rumor! :unamused: Let the other project try to enforce that interpretation of its own GPL license. You are talking anyway only about “add-on modules” to the AGPLv3 component that aren’t ours to worry about. Regardless of whether those add-on modules are AGPLv3 or MPL-HD or Apache or anything else open source, we (“OpenMRS”) can aggregate them like we can any other open source software. And they won’t infect any of the other independent stuff we (“OpenMRS”) aggregate with that component. (E.g., it is not our problem to worry about.)

So if they want to call that “strong copyleft,” that nickname at least only applies to that AGPLv3 component! It is their license; let them enforce it and call it strong or weak.

For the one-sentence summary of the OpenMRS licensing model:

Let our contributors give us great software under whatever certified (OSI-approved) open source license they want as long as it allows everyone (including us) the freedom to copy, freedom to modify, and freedom to distribute those works in source or binary form.