Open source EPANET license

The license of the open source EPANET project is one of the things we should discuss first. As far as I know, the official EPANET source code is either without a license or it is public-domain.

When coming to select a license we should consider and balance the interests, or views, of the general public, EPA, academia and commercial entities. I would consider one of the following licenses which all have a no-warranty clause:

  1. MIT - basically anyone can do anything but with attribution to the authors\contributors.
  2. BSD-2 - pretty much the same as MIT license but in fewer words.
  3. BSD-3 - same as BSD-2 but with a third clause which adds a restriction that the names of the contributors may not be used to endorse derived products.
  4. Unlicense - kind of public-domain. free for all uses with no attribution needed.

There are other, more restrictive, licenses such as the GPL and LGPL but I don’t think they are right for this project.

Personally I can go with Unlicense but if we want to have people credited for their contributions while allowing commercial users to use and hopefully contribute to the project we probably should go with MIT or BSD.

More information at (provided by GitHub).

What do you say?

Disclaimer: I’m not a lawyer nor an expert about software licenses, just a guy who likes EPANET and wants to contribute to the project.

This is a difficult and important question. I will give you some highlights from my research on the licensing issue:

  • If the project is anything other than Public Domain, then community contributions may never be allowed to be re-released by the USEPA. Also, US government employees may not be able to contribute to the project as they are not authorized to hold or assign copyright and their works are automatically in the Public Domain.
  • There is no recommended “bullet-proof” Public Domain license/dedication/statement that satisfies the intent in all legal jurisdictions
  • It is far easier to migrate a project to a more-restrictive license (re-licensing) than move to a less-restrictive license (modifying a license, which requires consent of all copyright holders).

All that said, there are a great many projects dedicated to the public domain like SQLite that have not received crippling legal challenges. On the other hand, I’ve seen a modified MIT license with acknowledgment of un-license-able public domain material created by US Federal employees (like here).

On balance, here is my take-away: since the probability of US Gov’t employees wanting to contribute to this project is non-trivial, and since there are big healthy projects that use PD that we can look to for guidance, I think adopting a dedication like that used by SQLite with a mandatory contributor dedication makes a lot of sense.

From the perspective of upstream users (software vendors), I will say that even though uncredited use of attribution-licensed code poses a legal risk to them, attribution is never guaranteed. Furthermore, attribution is still possible under a PD dedication. The question is whether the attribution is an important reason for people to participate, and what damage may result if attribution is not given.

CreativeCommons Zero is designed to make it easy to dedicate a work to the public domain, worldwide.

Dedicating works to the public domain is difficult if not impossible for
those wanting to contribute their works for public use before
applicable copyright or database protection terms expire. Few if any
jurisdictions have a process for doing so easily and reliably. Source

CC0 is well known and widespread however section 4a causes some concern for various foundations. By stating that no patent rights are waived, it creates a bit of a loophole. This discussion helped me understand the language and why the OSI doesn’t recommend using this dedication:

In my view we should aim to encourage attribution, but not to the extent that it prevents people from contributing (e.g. EPA employees). How about using a license that doesn’t require attribution, but adding a non-binding statement that encourages users to acknowledge the open source EPANET project in derivative products?

The SQLite project states that all contributors “signed affidavits dedicating their contributions to the public domain”, which are kept in a fire safe somewhere. This sounds way too heavy to me for our project. Surely we can simply make it a condition of contributing to the project that all contributions irrevocably fall under whatever license we choose?

Finally, what is the difference in how we apply a license and a disclaimer? We obviously need to ensure that contributors are safeguarded from claims of any sort, however unlikely these may be. Does this have to be part of the license or can ensure it through a statement in the code/software?

I agree with @kobusvanzyl, the SQLite license it complicated for us. The NPMap project claim to use the MIT but the modification removed the copyright notice (no attribution) and left the rest. As I said, I don’t need the attribution (it is nice to have and we can recommend\encourages it) and if this kind of version works also for EPA folks then I’m all for it.

Agreed, we can perhaps do without the fire safe :wink:

However, for many projects that maintain licenses, a simple digitally-signed contributor license agreement is sufficient. What if we took this approach with the public domain dedications? In fact, SQLite only requires original signed copies of the release for individuals acting as employee (who may be held to certain preexisting intellectual property assignment agreements). This is probably overkill. However, if our goal is a free and unencumbered code base, completely free of restriction, then this really is the gold standard.

Hi, to continue for licence topic, here are a few inputs.

Terminology : I am not sure of wording for these topics, since it is also different in European IP laws and Anglo-saxon ones.

  • “Droit d’auteur” -> Author’s rights : inalienable in European-style IP law. An author will always be credited for its creation, until the creation changes status to public domain.
  • “Droits patrimoniaux” -> Copyrights (has a larger meaning) or economic rights : what is allowed to do with a creation. This can be chosen by the author, and specified by a licence, and these rights can be passed on to others, which can in turn specify usage condition on the creation

For OpenSource Epanet :

Public domain is not an option as European-style IP laws prevent people to willingly put creation under this status

if no CLA has been signed by contributers giving copyrights ( = economic rights) to a specific institution, each one remains its own copyright on the piece of code it contributed. In this case the short copyright mention can state "Copyright xxx, " and have a file mentionning all contributors. The git history is enough to track back which piece of code belongs to whom.

The only problem in this case is if at some point you want to change the licence of the whole code, it needs agreement from all contributors. This can be very difficult to achieve and lead to loss of code ( see KDE or OpenStreetMap for such cases). But at the same time it is a guarantee that the licence will remain the same. It is distributed trust versus trust to an organization. In the case of a very permissive licence such as MIT, BSD or Apache, this is not a problem usually.

The patent issue is also important to deal with. The code should be free of any patent threat. There are two ways to ensure this :

  • Use an Apache v2 Licence, which is like MIT but with patent protection
  • Use MIT + a CLA

It is less cumbersome to use an Apache licence, as any contribution would already include patent protection without having to sign an agreement.

As for the issue of redistributing the code back to public domain, I think instead of removing the attribution part of the licence, adding a specific clause allowing public organization to release the source code as public domain should do the job.
This could also go to a CLA as an alternative.

CC0 have a Public License Fallback (section 3).

As for CC0, note that :

  • It can be applied to source code
  • It has not been recognized by the OSI though, and OSI does not recommand to use it for software
  • It has been recognized by the FSF
  • It does not handle the patent issue

Links :

I found questions 8.4 & 8.5 in this FAQ useful to understand the situation of US Government Employees:

In brief, govt employees are able to contribute to open source projects that have a license. But their contributions remain in the public domain and may be extracted.

One wrinkle in this instance is the status of the existing code-base as public domain. From the FAQ, it seems that govt authors are not able to ‘fork’ the code into a new project with a license. But, if there were such a project they could contribute to it. As the existing code is already public domain, anyone could fork it into a new project and there are several examples of this.

Could a path forward look like the following?

  1. Create a clear fork between the version on the EPA website and this new version. One possibility could be denoting the project as a community edition, Epanet-CE? or another name, released under a license.
  2. Require contributions to reference a developer certificate of origin ( Maybe two versions of such cert, do/do not hold copyright, are needed here.

Based on the above thread it seems like this approach would enable contributions from all interested parties.

Thanks @bradleyjeck for looking into this. There is another “complication” and maybe you saw something about that too.

I think we would like that the open-source version be “adopted” be the EPA and embedded for example with the GUI being rewritten (we just can’t have two version of EPANET). So we need the program to have such a license (or no license) that the EPA can use.

I hope I’m making myself clear.