Perimeter and topics suggestions

This first post will be a wiki to list and determine the topics that need to be addressed by the template open-source policy

Examples:

  • Professional and Personal contributions
  • Civil servants and subcontractors
  • Contribution to existing projects / New project contributions
  • Licenses
  • Compliance and Control
  • Contributor’s License Agreements (CLA)
  • Developers Certificate of Origin (DCO)
  • Personal and Organization account
  • Repositories and source code inventory
  • Code and project documentation
  • Build & Deployment
  • Expectation management (access to code =/= having expertise to change things) ?
  • Choosing between existing projects serving the same purpose (especially libraries) ?
  • Structure for hosting projects (foundation or other model, new or join an existing structure)?

Questions the contribution policy should be able to answer are:

  • How to recognize civil servants contributing to open-source?
  • How do we leverage and recognize contributions from subcontractors working for the government ?
  • How do we differentiate professional contributions from personal contributions?
  • How do we facilitate contribution ? What is preventing civil servants / subcontractors from contributing ? What can be pre-authorized ?
  • How do we keep track of contributed projects and commit rights?
  • How can a can a civil servant sign a CLA him/her self?
  • How do we improve our civil servants’ skills?
  • How do we improve government collaboration?
  • What are the best practices to respect and how do we avoid previous mistakes?
  • What is expected from governments by NGO and private companies ?

What is OUT of the perimeter ?

  • Open-sourcing existing code : extra steps should be considered
  • Why and what should be open-sourced
  • A open-source index (like the open-data index)

What cloud be annexed to the contribution policy ?

  • A how-to to help instantiate this policy for a government ?
  • A CLA template ?
2 J'aime

One of things I doubt is the need for a CLA at all. Some projects use them, but my understanding is that they discourage a lot of people from contributing.

The major experience I can bring from the Swedish government is that it’s important that governments should not own copyright to source code. Governments are not suited to be software distributors nor producers and should therefore make sure that all public funded software development is shared with everyone everywhere. If public money is used to enhance a community project, then the enhancement should be pushed upstream to the project.

1 J'aime

+1 on pushing back the enhancements to upstream (which also benefits the governments, since there is more change of getting the code into mainstream, meaning less maintenance costs)

On a related note, my advice is to always use the tools / repositories / ticketing system etc provided by the projects themselves, if possible (rather than creating a private repo inside the government for development and testing). Same benefit: saves tax payers money (less trouble in setting up ticketing systems), increases transparency and also easier when working with internal developers and external contractors.

1 J'aime

Bart, I fully agree.

Next up. Licenses. Should the template address that? Should it say « We recommend license X, Y and Z for governments » ? Or should we just say « Pick one approved by OSI »? I would prefer the latter with an addtion « If you have no idea, choose a modern license with broad use, like MPLv2, Apache 2.0 or GPLv3 »

Regarding « Civil servants and subcontractors ». Does it matter? If all code goes into something like Github and are pushed upstream I fail to see the relevance who wrote the code (in this context, from a copyright perspective it’s different)

1 J'aime

I’d only say something flexible / vague recommendation like « the most open license possible » and indeed suggest some well-know open licenses, as you mentioned.

Enforcing / selecting license(s) will not work. E.g. the European Commission created their own license (EUPL), which is basically GPL translated into European Law, which the EC is promoting for their (and EU-members) projects.

But in my organisation (Fedict, federal level in Belgium), we don’t use it because for some applications LGPL makes more sense (e.g. eID components: we’re interested in feedback for our libraries, but we don’t mind third parties creating closed -source software with them, because this increases options for businesses, hence we cannot use the GPL/EUPL in this specific project).

For new EU-collaborative projects, we might use the EUPL. For most of the quick and dirty tools, I use a BSD license. Or maybe we have to use GPL when combining existing libraries with new code… so it really depends. If working on existing projects, there is often little choice, and governments should not push another license (and most certainly not create a new one…)

On the topic of subcontractors, my point is that it would be good to use existing public ticketing / repositories (can be forked on github of course, if the project is on github).

What I personally don’t like is subcontractors copying the code in their own private system (instead of the project community repo) just because they always do it that way, then start developing stuff and committing the code one year down the road: in the mean time, bugs may be reported in one ticketing system, but not in the other, code has to be synchronised etc, and another participant cannot step in as easily.

So perhaps rephrase it to say « should commit to mainstream (or a public branch) on a regular basis » ? Would that make sense ?

1 J'aime

Hello @BartHanssens and @Daniel,

thank you very much for your contributions. From your inputs we definitely need to have a topic on licenses so I will create the obvious ones to start the conversation on what we can expect for the template policy.

What I would like here is really to have a discussion on the perimeter. Each « border » of the perimeter or question / issue that need to be addressed would then be discussed on a specific topic in this forum. We should then be able to define a « Table of content » of the template policy and start drafting some text proposals for the policy.

Regarding the CLA, the question should be asked both ways:

  • How can a civil servant sign a CLA that is required by an open-source project: even if this has to be instantiated localy, I believe the goal would be to allow the developer to directly sign the CLA without requiring any internal or management approval to do so if the code license is OSI approved for example.
  • For a new open-source project started by a government should CLA be part of best practices? In what cases? And should a dedicated organization be created so that CLA are not owned by governments?

Regarding subcontractors, I wanted to address this subject because in France, a large majority of code produced by government money is made by subcontractors. If we set a ground principles that contributions should be attributed nominatively, what are the prerequisite and best practices to allow this. Restricting the contribution policy to the civil servants only would reduce its impact. Without starting the subject here, should specific legal terms be added to the public tender, would a subcontractor save a commit using its private company email address or an « external » government email address, etc. ?

You are setting a ground principle that government should not seek to be software editors, and that we should by all means try not to own any copyright. This is also something interesting to discuss.

Then both of you are listing best practices:

  • avoid forks and contribute upstream
  • for a new project contributed by the government, provide not only the code but the tools to manage issues, history, etc.

To sum things up, I would really like this topic to ask questions, raise issues and set principles that need to be discussed in other topics. Here I would like to discuss if something is relevant or not, and for example, maybe the subcontractor issue should not be part of the problems the contribution policy is trying to address.

1 J'aime

I forgot to mention that the first post is a wiki that anyone can edit. This will allow to find easily the actual perimeter based on the discussions in this topic.

Hmz, it looks like I’m only able to edit my own posts, not the wiki on top (no « pencil ») underneath the first part

Same for me. Cannot edit anything except my own posts.

Sorry, Discourse requires that you have a basic trust level to be able to edit a wiki post. This is now effective for both of you.

1 J'aime

Regarding documentation, I would argue this is a requirements when contributing a new project. Documentation should also be accessible and under a creative common license. Should we all agree that the template policy should include this?

+1 on documentation (both technical / code documentation and other materials, e.g user guides or short introductions)

I am not sure I understand this suggestion:

  • Choosing between existing projects serving the same purpose (especially libraries) ?

For me, a maturity model to choose the right software is out of the scope of the contribution policy. Do I understand this correctly as having criteria on how to choose the right software and maybe also have specific criteria for contribution?

I’ve added « Structure for hosting projects (foundation or other model, new or join an existing structure)? »

Maybe worth listening to this : https://www.youtube.com/watch?v=ybAiTpqanDY in providing elements for that answer?

1 J'aime

Hello,

after the POSS we suggested the following structure to be able to adapt to the various expectations of governments regarding this policy:

  1. We need a general introduction for government officials to understand why such an open-source contribution policy is interesting.

  2. A small guide on how to instantiate the document and what preliminary work is required on the government side

  3. Explain how to contribute to the policy template and how it will evolve (likely to be a pointer to another document describing the governance)

Then the open-source contribution policy template in itself that will describe

  • General principles and if they are optional or not

  • Rules that are part of the policy

  • A detailed / best practices part that each country can adapt to its needs

1 J'aime

Hello everybody,

sorry that I just enter the discussion now (beside my discussions with Polina). It is a bit difficult to participate in a forum, when you are travelling.

For me it is currently a bit difficult to contribute because it is still unclear what our goals are? Was there already an agreement about that? Or is that what you mean with « rules that are part of the policy ». My impression is that if we have an agreement, what which goals we want to achieve it will also be way easier to structure it and fill the other missing parts.

What do I mean with « goals » in this context? Something like:

  • Public bodies should publish percentage X under a Free Software license
  • Public bodies / governments should highlight that developing Free Software counts as volunteer commitment and good service for society
  • Public bodies should invest into Free Software infrastructure
  • Public bodies should give good actors, who publish Free Software, financial benefits (increase their budgets, allow them to keep savings, …)
  • Public bodies should foster business by making support contracts with Free Software businesses.
  • If a Free Software solution is not yet viable, public bodies should invest 10% / 5% of the money they spent on the proprietary solution to a Free Software solution so it gets competitive in the long run.

Please let me know if I missed something before, or where this discussion would make sense.

Best Regards,
Matthias

1 J'aime

Hello Matthias,

Thanks for joining the conversation. I totally agree that we should focus on the objectives. Regarding the goals:

This could be an interesting approach and is actually the case of the USA regarding the federal source code policy. In the case of the contribution policy template, the choice to open up source code is already made and is a prerequisite. The goal of the policy is to focus on the How and not on the Why or What.

If I agree I don’t understand how this can be valued. Remember that this policy is aiming civil servants and subcontractors. Recognizing their individual contributions to free software is a way to value the work. To me, it is more than volunteer commitment since it might also be the right way to develop certain kind of software. It is important that governments recognize individual contributions wether the contributor is a civil servant of a subcontractor. In France with the digital republic law, code should be opened by default. Even if it was not the case, I would like a civil servant to be able to release free software and that there is no administrative barrier to do so. We need express authorization so that no direct manager can forbid it (without justifying for security purposes and so on).

What do you mean by that ? Have a financial support to key free softwares ? In that case wouldn’t the best way to have a financial contribution to foundations like the core infrastructure initiative of the Linux foundation https://www.coreinfrastructure.org/ to avoid the lobby risk of having a government directly support the development of privacy related components such as gnupg ?

If this is not directly related to the template, I still believe it is an interesting idea that can be described as an easy best practice in the introduction part. Please let me know if I did not understand you correctly.

In the end, I don’t know in what way a government can contribute to charities. In France I believe the only way is that the citizen can reduce its tax based on the amount given to public interest charities. It would have to be a international subsidiary effort that we could discuss during the workshop.

Not sure to understand and seems very vague to me. Budgets are granted within the administration based on their missions. Free software is a way for them to do more with less and maximize reuse.

This is another topic that is out of scope of this policy. General support contracts for free software is a very interesting subject in France. We can have a special discussion around this if you want. What would be in the scope of this policy are best practices to follow for contributing patches in the scope of those support contracts.

Next to support contracts, governments could request that a custom developments should be made as free software. Again if the goal of the policy is not the Why and the What, it should focus on how those subcontracted developments can be made. For me the same principles should be applied and individual contributions should be recognized. The difficulty would be that no general pre-authorization can be granted beforehand and contractual clauses should be present in the public tender with the contractor to allow those free software developments. This would clearly be in the scope of this policy. In France I would add a pointer to legal contractual clauses that need to be in the public tender, and complete with best practices that should be respected by the government and by the subcontractor (public repository not owned by the subcontractor, etc)

The prime minister memorandum on free software in France propose the same kind of idea. This might be difficult to organize and depends on the purpose of the software. For me it is out of scope of the policy since it should be triggered once the decision has been made to release free software.

1 J'aime

Public bodies should invest into Free Software infrastructure

Slightly off-topic perhaps: you may also be interested in CommunesPlone, which started out as a tiny project with two small villages in the Walloon Region (Belgium) who couldn’t afford a new website / CMS on their own, but decided to work together and share the costs.

They funded the development of extra modules on top of the open source Python-based Plone CMS, and it became a huge success and the foundation of an open source strategy / policy and the spin-off « IMIO »

http://www.uvcw.be/impressions/toPdf.cfm?urlToPdf=/articles/0,0,0,0,1837.htm
http://www.imio.be/presentation/presentation
http://www.imio.be/solutions/logiciels-libres

Public bodies / governments should highlight that developing Free Software counts as volunteer commitment and good service for society

I think it is also the other way around: when deciding who to hire and/or award a contract to a vendor, it is easier to check if a person or company is delivering good quality software (code quality, documentation) when they can show the contributions they’ve made to open source projects.

1 J'aime