Open-sources licenses choice

Gouvernement ouvert Open-Source Contribution Policy
#1

What should the contribution policy say on licenses:

  • Nothing else than : please use any OSI approved license?
  • Give a decision tree based on use cases? (ex: http://choosealicense.com/)
  • Rationalize and impose a license (for example 18F is using CC0, alphagov is using MIT) that can be shared across governments?

When contributing to an existing project, for the majority of the cases, there is no choice but to use the project’s license. If the license is OSI approved the civil servant / subcontractors can contribute without any approval required. If it isn’t, should it ask for help?

When releasing a new project, the question is critical.

1 J'aime
#2

As mentioned in another post: for new projects, I’d go for recommending on choosing « the most open one », without enforcing any license in particular (but of course there can be some suggestions like BSD, MIT…and/or OSI approved)

+1 on not having to ask for approval on publishing/using.

FWIW, in some jurisdictions, there are interesting cases for lawyers (Freedom of Information acts, PSI directive on open data and whether or not code is considered to be data / document vs laws or contracts about copyright and ownership vs licenses like AGPL requiring that changes are to be shared)

#3

Duplicate of Quelles licences pour les logiciels libres du secteur public ??

#4

Hello Matti,

you are right but it would be better to continue the conversation here in English for the purpose of the open-source contribution policy workshop. From your post, we should have a debate on what option should the government prefer:

  • Permissive licenses?
  • Reciprocal licenses?

If USA and UK have chosen permissive license (CC0 and MIT) over reciprocal ones , maybe some use cases about the nature of the software should be included. AGPL for software never accessed through the network might be overkill and may refrain potential contributors.

So we end up with the three basic uses cases slightly different from choosealicense.com

  • Remote Reciprocal : AGPL
  • Reciprocal: GPL
  • Permissive : MIT / Apache 2.0

On this last topic, you might find the following post interesting: https://blog.gerv.net/2016/09/gplv2-combination-exception-for-the-apache-2-license/ (Gervase is actually part of the workshop, so it would be interesting to have his point of view)

Then should we orient on a particular type of license based on the nature of the software: administration website, infrastructure tool, etc. ? In my opinion, no general rule can be set and it is better to let the project decide and provide consulting if they need help.

1 J'aime
#5

For software developed with private company, particularly SME, I think it could be easier to convince them to go for a reciprocal licence (GPL or AGPL for web applications). Those licence enforce fair-play from other companies.
Also requiring reciprocal licence ensure a positive loop with the private sector: an application made for administration might prove useful to private sector (or associations), can be enhanced and those enhancement might in turn prove useful to public sector.

#6

I think it is unlikely that you will solve the permissive vs. copyleft question here. If this is a contribution policy template, I think it should say the following things about licensing:

  1. Government employees and contractors should be permitted to contribute to any project under an OSI-approved licence, unless requested not to do so by their management.
  2. Contributions to existing projects should be submitted under the license of that project.
  3. Employees should be empowered to sign CLAs as part of that contribution, excepting that they should not sign CLAs with commercial entities for projects using copyleft licensing.
  4. When starting a new project, there should be a flowchart for license choice. We should provide a template flowchart, but administrations can of course alter it. That flowchart will take in questions like « is there a standard license for projects in this language (e.g. Perl, Rust) », and « what are your licensing goals for the project »? Developing a fair version of such a flowchart is a good activity for this group.

I should explain 3) more. CLAs are a pain in general, but they are actively unfair if a commercial entity is collecting copyright assignments or effective equivalents for copyleft code, because then they have an unfair advantage over other users. Governments should not give away taxpayer-funded work like that.

1 J'aime
#7

Hello!

The most permissive one isn’t always the best. Sometimes you want to enforce contributing back additions to code with something like the GPL, rather than BSD. There are advantages to licenses like Apache or MIT.

Chosing a license will depend on each individual project. Suppose it’s integrated code for an appliance or a server-side component, it will be different than if it’s code that is aimed at running on a browser (Affero GPL would be interesting there to enforce rights even on web-distributed code).

One thing that is really important is to avoid license proliferation. Maybe select a few specific ones for large families of categories… and encourage picking one of those for every new project. Maybe limit to 5 or so licences. I remember a time when, at Sun Microsystems, we reduced the number of licenses for our internal projects from over 200 to less than 20… Lots of work to do… but once done, simplified many things!

#8

When one has a greenfield development, the license options from a license picker should include only modern licenses with patent clauses. This excludes BSD and MIT. The permissive option should be Apache 2.0, the copyleft option GPL 3.0, and the network copyleft option AGPL 3.0.

Of course, greenfield development is rarer than one might think. Software is normally written into a context.

1 J'aime
#9

Thank you very much for your input that is very interesting and for which I strongly agree.

  1. This could be stated as a general rule of the template policy with a link reference to all OSI approved licenses.
  2. OK
  3. Interesting but will probably bring some confusion. I agree that it has nothing to do with the NC clause of CC licenses (you can check if the CLA is for a foundation or a private company), but why would government « trust » more a NGO over a private actor not to abuse of the unfair advantage to own the copryright? Also not signing a CLA might simply prevent contributing to that project, so this warning should be raised when choosing the software and not once you want / need to contribute (and hence would be out of the perimeter of this policy). For this reason I would not make this distinction about the type (commercial or non-commercial) of the final entity.
  4. Totally agree. I believe the choices for this flowchart could be discussed in this thread. I also totally agree with the licenses choices you keep: Apache 2.0, GPL 3.0 and AGPL3.0 (with an interesting option you pointed for Apache 2.0 when compatibility with GPL2.0 is required.

If I were to sum things up, I believe governments and administrations should not own software copyright and if it is the case it should be only temporary. This could be a ground principle for the template policy.

Based on another topic (distinguish private and professional contributions), I also believe that a ground principle is that we should recognize individual contributions. Even if I understand the philosophical reasons to publish administration code as CC0, no successful project will be 100% developed by civil servants during their professional time. For this reason, I would not add the CC0 for code, even if it is a very interesting choice made by the USA, and we should discuss it further.

Now with those two principles, as governments, the questions should be where you want to create « competition » and if the software is meant to be a digital common.

  • If the purpose of the software is to be an infrastructure, or part of the « State as a Platform » approach, it should not create any competition and permissive license should be chosen (ie Apache 2.0)
  • If the purpose is to great a digital common that could be used to create competition between actors of the civil society, whether private companies or NGO, a reciprocal license should be chosen without remote clause (GPLv3)
  • If the purpose of the software is to maintain an active link with the citizen and a « no competition » between actors should be enforced, a remote reciprocal license should be chosen (AGPL v3) (competition between f/oss projects is always interesting)

Now licenses are not the only questions in the case of a greenfield development. Should governments have CLA? I suggest a specific topic on the subject : Contributor's license agreement (CLA)

What about governance and organizations? Another topic here: Organizations, accounts, governance and commit rights

1 J'aime
#10

Regarding the flowchart idea, a simple and interesting document made by Mozilla is available here: https://www.mozilla.org/media/img/mozorg/mpl/license-policy-flowchart.3d01662c2c7d.png

#11

And here is the flowchart made by British Columbia : https://github.com/bcgov/BC-Policy-Framework-For-GitHub/blob/master/BC-Open-Source-Development-Employee-Guide/Licenses.md