Further discussion on license mixing with other open source projects

But AFAIK, we still don’t yet actively maintain a NOTICE file. Isn’t that a problem?

Yes. /Larry

Through some informal polling, it sounds like many of our developers are confused about the NOTICE file and that it is not necessary to have a “© OpenMRS Inc.” in license headers.

Should we create some type of guide like http://www.apache.org/legal/src-headers.html to help?

Michael, I strongly suggest we do that.

Of course developers don’t want to write notices. And they definitely don’t want to make them into complicated tomes. But those who use our software and who will re-distribute it around the world need to know where our software comes from. Notices can be brief but should be complete. [But write your own guide. Don’t copy the Apache guide, since that group is very bad also at writing actual notice files.]

/Larry

1 Like

How do people feel about this NOTICE file that we have for the radiologydcm4chee module:

1 Like

This is great information to pass on to future users and redistributors of the radiologydcm4chee module. A NOTICE file doesn’t have to be much more noticeable than that!

Any other examples to share?

We can also work on general-purpose introduction text for the top of the NOTICE file that includes all the required OpenMRS copyright, trademark and MPL-HD notices.

Can you provide an example? At first it sounds like it would be redundant with LICENSE, but maybe I’m missing something. :slightly_smiling:

********* NOTICE FILE EXAMPLE BELOW **********

Copyright © 2016 OpenMRS Inc. OpenMRS is a registered trademark of OpenMRS Inc.

This program and its individual component files are all open source. They are distributed around the world by the OpenMRS project under the MPL-HD license, a copy of which is in the LICENSE file. You may freely copy, make modifications, and distribute those works to others under the terms of this copyleft MPL-HD license. Individual components of this program may also be available under their own open source licenses with their own terms and conditions, as described more fully below.

---- The text from sunbiz can go here ----

2 Likes

A different instantiation of this issue: HISP India has built a dhisreports module that we (OpenMRS leadership) want to start pushing as the recommended way of doing OpenMRS-DHIS2 integration. The module is licensed as GPLv3: https://github.com/hispindia/dhisreport/blob/ADX/LICENSE.txt.

From this conversation, there’s no legal or licensing problem here, and it’s perfectly fine for us to start including a GPLv3 module in our distributions.

However…I would really like to affirmatively hear that the OpenMRS Leadership Team philosophically/politically approves of having the OpenMRS party line be to recommending and trying to organize contributions around a particular effort that has a “more copyleft” license than our MPL-HD one.

Personally my vote is that this is fine. (And this example seems less problematic than the original one in this thread, because this example is just one add-on module that 99% of people would use but not modify, and hence not be affected by the licensing details. Whereas the original hypothetical example would be about the foundation of a new UI, which we’d expect more people to need to make modifications.)

3 Likes

I approve of it, for sure. I believe in our contribution policy and what it stands for.

I am personally a strong supporter of copyleft, and think we should always welcome work under such license, but should we be recommending the default (rationalized exceptions welcome) be MPL-HD for consistency and simplicity?

In this case, the HISP India folks wrote a bunch of code and licensed it under GPLv3. It’s important code that we can and should extend for the betterment of the community, and release that package as MPL2-HD. They have invited us to do so.

I’ve talked with them about their choice of GPLv3 in the past (they have a stronger commitment to copy-left ideals), and it’s a slight distinction in philosophy that ultimately isn’t discongruent with ours. Its a good example of what you referred to above as the “rationalized exception” :slightly_smiling:

2 Likes

[An issue about the AGPLv3 license came up in my discussions with some Google attorneys about another matter. I was told that their company has a “blanket ban” on AGPLv3 software. I wrote them the following. I don’t mention OpenMRS or my other client by name. I’m republishing it here for you under CC-BY 4.0.]

Use of AGPLv3 software over a network

One of the non-profits I also advise distributes open source medical software under the MPL-HD license that will be used around the world. “HD” stands for “Healthcare Disclaimer,” an essential additional disclaimer of liability for this healthcare software. This MPL-HD license is itself compatible with GPLv3 and Apache licenses. Open source code sharing under lots of licenses runs apace in that project.

This non-profit is considering using a particular AGPLv3 component for implementing a user interface (UI), and they expect that code to be modified frequently around the world for (among other things) language differences. They thus faced the question of including an AGPLv3 component in their collective healthcare software, knowing that redistributors of that software over a network (perhaps commercial companies like Google?) would have potentially uncomfortable copyleft obligations for derivative works.

It was important to some project participants that this is only a UI component and so it is not on the critical path to healthcare delivery. Modifications to this UI component can reasonably be copyleft and disclosed to network users without impairing the social goals of this open source healthcare non-profit. And if downstream users are willing to use only the original AGPLv3 UI version without creating derivative works – the code is free and the copyleft obligations are as trivial as those in the MPL-HD license itself!

So in this healthcare software organization, deciding whether to avoid AGPLv3 software is a business decision that can’t be addressed by a simple “blanket ban” on AGPLv3 software.

Suppose a company like Google were asked to participate in this world healthcare non-profit through its growing telecom networks. Should they avoid this AGPLv3 software alternative entirely through their blanket bans on that license? Or can they satisfy its basic copyleft obligations merely by publishing the license and that code on their website? In the case of an AGPLv3 UI component, perhaps Google instead would just write their own code from scratch and replace the AGPLv3 component so they don’t have to disclose their derivative works? Or would Google – and other potential UI software customers – pay for a commercial exception to the AGPLv3 if one were offered by that UI software vendor?

BTW, I don’t know the name of that AGPLv3 UI software contributor. But I know that it can be a successful open source business model and none of this is an evil software business. It results in more great open source software available around the world.

/Larry Rosen

[@burke, @michael: A NOTICE file will be needed for OpenMRS Release 2.4. Below is a draft.]

Copyright © 2016 OpenMRS Inc. OpenMRS is a registered trademark of OpenMRS Inc.

This program (“OpenMRS Release 2.4”) and its individual component files are all open source. They are distributed around the world by the OpenMRS project under the MPL-HD license, a copy of which is in the LICENSE file. You may freely copy, make modifications, and distribute those works to others under the terms of this copyleft MPL-HD license. Individual components of this program may also be available under their own open source licenses with their own terms and conditions, as described more fully below.

[Below this the “Release Notes 2.4” drafted by @burke.]

[Below this identify all components of this Release 2.4 that are under an open source license other than MPL-HD.]

1 Like