EU Commission to open source software(ec.europa.eu)
ec.europa.eu
EU Commission to open source software
https://ec.europa.eu/commission/presscorner/detail/en/ip_21_6649
12 comments
Keep in mind that the open source projects being mentioned as examples on this press release only tend to affect people established as residents in the European Union.
For example, from the press release:
> “ An example of the benefits of open sourcing is eSignature, a set of free standards, tools and services that help public administrations and businesses accelerate the creation and verification of electronic signatures that are legally valid in all EU Member States.”
In order to use an eSignature, you need to have an eID (electronic ID) card from an EU member state, which is placed in a smart card reader. Some people in the EU do not have eID cards yet. Yes, some countries have apps that allow you to use an eSignature, but generally speaking, your eID is your best bet. Typically, your eID provides the highest authentication level, in terms of security, when dealing with EU or national (country) level services.
For example, from the press release:
> “ An example of the benefits of open sourcing is eSignature, a set of free standards, tools and services that help public administrations and businesses accelerate the creation and verification of electronic signatures that are legally valid in all EU Member States.”
In order to use an eSignature, you need to have an eID (electronic ID) card from an EU member state, which is placed in a smart card reader. Some people in the EU do not have eID cards yet. Yes, some countries have apps that allow you to use an eSignature, but generally speaking, your eID is your best bet. Typically, your eID provides the highest authentication level, in terms of security, when dealing with EU or national (country) level services.
> In order to use an eSignature, you need to have an eID (electronic ID) card from an EU member state. Some people in the EU do not have them.
This is false. eIDs are a common way of doing it, since they already have a process for verifying identity obviously and are smartcards matching the required security level, but not required, you can just get a generic matching smartcard loaded with the cert.
This is false. eIDs are a common way of doing it, since they already have a process for verifying identity obviously and are smartcards matching the required security level, but not required, you can just get a generic matching smartcard loaded with the cert.
In practice, countries recognize only eID cards they produced and signed themselves (well, ordered from Gemalto, Giesecke and Devrient or IDEMIA).
Now, once the use of eID cards expands, all these use cases will require software. So far, countries do on their own. Belgium writes its own software, Estonia as well. The point is that most of that software could be reused.
So far, only open source parts are reused, like opensc.
Now, once the use of eID cards expands, all these use cases will require software. So far, countries do on their own. Belgium writes its own software, Estonia as well. The point is that most of that software could be reused.
So far, only open source parts are reused, like opensc.
The Estonian e-signature software is fairly well written, open source and easily extensible to other countries eIDs. Latvian and Lithuanian are already supported.
>Typically, your eID provides the highest authentication level, in terms of security, when dealing with EU or national (country) level services.
Not really, at least in here (Poland). "Qualified electronic signature" which you can buy from several approved suppliers, provides highest authentication, you can use access all government services with it and is legally equivalent to paper signature. Meanwhile "personal signature" you get on government issued electronic ID is not eIDAS-compliant, isn't equivalent to paper signature, and some government services are not available (like these VAT tax forms using Adobe Reader plugins, ugh).
Not really, at least in here (Poland). "Qualified electronic signature" which you can buy from several approved suppliers, provides highest authentication, you can use access all government services with it and is legally equivalent to paper signature. Meanwhile "personal signature" you get on government issued electronic ID is not eIDAS-compliant, isn't equivalent to paper signature, and some government services are not available (like these VAT tax forms using Adobe Reader plugins, ugh).
However, if there's part of the software that is useful outside the EU, there would be the option of reusing just that part.
> The Commission will make its software available as open source in one single repository
Let's hope this is not a git monorepo...
I wonder where they will release it? Github would be the easy choice. They could self-host a forge or just a web frontend, publish tarballs, etc.
An interesting choice would be to use SourceHut, which is now based in the Netherlands with ddevault. (edit: well, maybe it's still incorporated in Delaware).
Let's hope this is not a git monorepo...
I wonder where they will release it? Github would be the easy choice. They could self-host a forge or just a web frontend, publish tarballs, etc.
An interesting choice would be to use SourceHut, which is now based in the Netherlands with ddevault. (edit: well, maybe it's still incorporated in Delaware).
A self-hosted Gitlab instance would make the most sense, IMO.
Well, given the resource requirements to host GitLab and the number of potential visitors, I think this is unlikely.
Moreover, I wouldn't be surprised if they just opened the code, not the development process. And old, frozen projects with no contributing directions are most likely what we'll get at first.
However, hosting OSS code like this is a public service. It would be nice to see the EU commission competing against GitHub for Open Source hosting, but that's probably a pipe dream for now.
The really promising part is what this will enable going forward:
> The dissemination of software under an open source licence will no longer require a Commission Decision.
> The Commission now allows its software developers to contribute to open source projects with improvements that they developed as part of their work.
So it might become at the team's discretion. The code will probably end up being developed on GitHub or somewhere else, with a mirror of sorts on the EU commission's "repository" website.
Moreover, I wouldn't be surprised if they just opened the code, not the development process. And old, frozen projects with no contributing directions are most likely what we'll get at first.
However, hosting OSS code like this is a public service. It would be nice to see the EU commission competing against GitHub for Open Source hosting, but that's probably a pipe dream for now.
The really promising part is what this will enable going forward:
> The dissemination of software under an open source licence will no longer require a Commission Decision.
> The Commission now allows its software developers to contribute to open source projects with improvements that they developed as part of their work.
So it might become at the team's discretion. The code will probably end up being developed on GitHub or somewhere else, with a mirror of sorts on the EU commission's "repository" website.
> It would be nice to see the EU commission competing against GitHub for Open Source hosting
Why would you want them to get into that? It doesn't seem like it's something appropriate for a government to get into.
Why would you want them to get into that? It doesn't seem like it's something appropriate for a government to get into.
While 'competing' may not be a good word for it, there's an argument to be made that some software belongs in the commons. This sort of signature/certificate infrastructure is a good example.
So why not have it hosted by a public entity? Maybe entrust a couple large libraries with operating and cross-mirroring repositories?
There a large popular Gitlab instance in Europe already but ofc EC is free to host its own: https://framagit.org/
Existing Gitea instance for FOSS-only is a nice option. Codeberg is hosted in Germany and contributes to the wholly community-driven Gitea project: https://codeberg.org
Maybe they first start a 5 year project to create an apropriate vcs infrastructre...
On a mainframe
This should be the norm for software developed as work for hire for all kinds of governments, everywhere, if only for the reason that it would save a lot of redundant development of software used by governments. There are obvious exceptions for weapons technology. But the presumption should be that governments must look to existing open source software before they contract for software development, and they should contribute newly developed software to the pool.
The workflow is not trivial though: (assuming the relevant systems are critical) you must also have a number of security experts monitoring the code full time, delaying the in-production stage accordingly...
Interestingly, the fault tolerance is increased, as less care from some project beneficiaries will be compensated by the extra care of others (instead of the former being just liabilities).
Interestingly, the fault tolerance is increased, as less care from some project beneficiaries will be compensated by the extra care of others (instead of the former being just liabilities).
Absolutely agreed. Public money, public code. So much software can be shared between various governments it's not even funny how much money was wasted on useless huge vendors like Accenture and IBM.
I like the sentiment, but have struggled on mechanism. Basically, we need to incentivize creating & running good OSS projects: the more direct the incentives, the harder for non-maintainers to game the system.
I suspect the current proposal tilts the bias even further to consulting companies who explicitly rather compete on butts in seats writing code vs OSS product teams wanting to build quality code that minimizes servicing needs. On any individual contract, the product team would be more expensive and thus less competitive, and no longer have a proprietary advantage built up over time to defend against that: the services team can hack the same code.
My observation is 100% as a product person who sees these bids go out and contractors take either most or all of a contract because of this dilemma. If we open sourced even more, we'd get even less interest, despite writing measurably better code.
Instead, I've been thinking something like "X% budget / yr should be grants to SMB OSS project maintainers" based on a few flavors (gov use, commercial use, ...). Incentivize creating popularly used OSS, vs more services. Like take the SBIR budget and make a 20% match to SMB OSS. Maybe a DAO that'd actually help :)
I suspect the current proposal tilts the bias even further to consulting companies who explicitly rather compete on butts in seats writing code vs OSS product teams wanting to build quality code that minimizes servicing needs. On any individual contract, the product team would be more expensive and thus less competitive, and no longer have a proprietary advantage built up over time to defend against that: the services team can hack the same code.
My observation is 100% as a product person who sees these bids go out and contractors take either most or all of a contract because of this dilemma. If we open sourced even more, we'd get even less interest, despite writing measurably better code.
Instead, I've been thinking something like "X% budget / yr should be grants to SMB OSS project maintainers" based on a few flavors (gov use, commercial use, ...). Incentivize creating popularly used OSS, vs more services. Like take the SBIR budget and make a 20% match to SMB OSS. Maybe a DAO that'd actually help :)
5M EUR wasted on an open source editor for writing legislation:
https://ec.europa.eu/isa2/actions/open-source-software-editi...
Git and Markdown would do a better job, XML is insane.
https://ec.europa.eu/isa2/actions/open-source-software-editi...
Git and Markdown would do a better job, XML is insane.
XML is not insane, actually it’s an open standard for writing legal documents: https://en.m.wikipedia.org/wiki/Akoma_Ntoso
Legal text is not prose, it does have structure and metadata attached to it.
Legal text is not prose, it does have structure and metadata attached to it.
> Public money, public code.
That's the slogan of https://publiccode.eu
That's the slogan of https://publiccode.eu
This is great. I've long thought that every line of code developed with govt. money should be open sourced, and that a country that got serious about this would likely get a lot more people interested in working for them.
Next step. Make sure EU Government paid contractors release source code per LGPL https://github.com/OpenSC/OpenSC/issues/2462
Someone almost made the Bulgarian government do that a few years ago. I think it went nowhere though
Hopefully there can be EU supported remedies for GPL violations. It's kind of absurd. The Estonian eSignature software (FOSS) could fairly easily automatically support many countries eSig, IF the drivers are added to OpenSC ...
Sorry for the highly editorialised title, the original one is very bad and marketingy, and also far too long for HN.
This is definitely a good move, but I was hoping the EU would also announce investment into current open source projects. Maybe a program for people to present their OS project and get funding.
Pretty sure they already fund some open source projects
EU also fundsled foss research and security audits, but no idea whether that was one off or regular
https://joinup.ec.europa.eu/collection/open-source-observato...
https://www.zdnet.com/article/eu-to-fund-bug-bounty-programs...
And they fund lots of projects, SMEs, NGO work, etc
https://protonmail.com/blog/eu-funding/
https://www.ngi.eu/ngi-projects/ngi-zero/
And do lots of policy stuff in the space, e.g. annual policy conference
https://opensource.com/article/21/3/linux-powers-internet
https://joinup.ec.europa.eu/collection/open-source-observato...
https://www.zdnet.com/article/eu-to-fund-bug-bounty-programs...
And they fund lots of projects, SMEs, NGO work, etc
https://protonmail.com/blog/eu-funding/
https://www.ngi.eu/ngi-projects/ngi-zero/
And do lots of policy stuff in the space, e.g. annual policy conference
https://opensource.com/article/21/3/linux-powers-internet
The EU runs bug bounty programs for open-source software. But I'm not sure if the EU directly funds open-source projects.
https://ec.europa.eu/info/news/eu-fossa-bug-bounties-full-fo...
https://ec.europa.eu/info/news/eu-fossa-bug-bounties-full-fo...
Source?
They already do that. Check out https://nlnet.nl/ and other NGI programs.
Any idea what license(s) they'll use?
A good guess would be EUPL which is written to work within the european copyright framework https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-1...
It works much in the same way as AGPL
Edit:
As per decision https://ec.europa.eu/transparency/documents-register/detail?...
> the open source licence granted by the Commission shall be the EUPL, except in the
> cases listed in points (b) and (c);
It works much in the same way as AGPL
Edit:
As per decision https://ec.europa.eu/transparency/documents-register/detail?...
> the open source licence granted by the Commission shall be the EUPL, except in the
> cases listed in points (b) and (c);
> It works much in the same way as AGPL
I'm not 100% knowledgeable on the topic but wasn't the issue with (A)GPL that even linking libraries in the runtime to your project would mean that your project can't be proprietary?
With EUPL this doesn't seem to be the case:
From https://joinup.ec.europa.eu/collection/eupl/news/eupl-and-pr...
> This makes no obstacle for linking Code A with another software component (Code B) that could be proprietary. There is no kind of “viral effect” resulting from the EUPL licence, in so far linking is done for interoperability. The portions of Code A that are strictly necessary for interoperability may be reproduced in Code B without copyright infringement. The resulting “A-B solution”, which could be commercial, will include the two modules under their relevant licences. This is resulting from interpreting European law and case law[1].
I'm not 100% knowledgeable on the topic but wasn't the issue with (A)GPL that even linking libraries in the runtime to your project would mean that your project can't be proprietary?
With EUPL this doesn't seem to be the case:
From https://joinup.ec.europa.eu/collection/eupl/news/eupl-and-pr...
> This makes no obstacle for linking Code A with another software component (Code B) that could be proprietary. There is no kind of “viral effect” resulting from the EUPL licence, in so far linking is done for interoperability. The portions of Code A that are strictly necessary for interoperability may be reproduced in Code B without copyright infringement. The resulting “A-B solution”, which could be commercial, will include the two modules under their relevant licences. This is resulting from interpreting European law and case law[1].
So EUPL is to AGPL what LGPL is to GPL?
To paraphrase, EUPL would be the LGPL of AGPL? LGPL where "distribution" also means "distributing the output trough a webpage".
One of the major advantages of LGPL is that users can link their own modified libraries, so that analogy doesn't hold all the way, but linking is permitted and non-viral.
To paraphrase, EUPL would be the LGPL of AGPL? LGPL where "distribution" also means "distributing the output trough a webpage".
One of the major advantages of LGPL is that users can link their own modified libraries, so that analogy doesn't hold all the way, but linking is permitted and non-viral.
I'd concur, but careful with the wording.
Distribution requires user interaction, not pregenerated output from an internal tool.
".. or providing access to its essential functionalities at the disposal of any other natural or legal person."
Distribution requires user interaction, not pregenerated output from an internal tool.
".. or providing access to its essential functionalities at the disposal of any other natural or legal person."
Scanning the EUPL quickly, it seems to me that it's actually much closer to weak copyleft (EPL/MPL/LGPL-like), especially because one of the clauses actually lets you distribute the work solely under the terms of those licenses.
There is the possibility that GPL's viral nature is not actually fully possible in EU and EUPL is "the most" you can get copyleft-wise there. There are two articles about it on the EC's site:
https://joinup.ec.europa.eu/collection/eupl/news/why-viral-l...
=== (relevant snippet)
As a conclusion, it looks that in most cases, linking two programs or linking an existing software with your own work does not – at least in Europe – produce a derivative or extends the coverage of the linked software licence to your own work.
Such interfacing or linking escapes to the copyleft provision of any licence, open source (like the GPL) or proprietary. The technical way of linking for interoperability (static or dynamic, permanent or temporary reproduction of the needed code) should not make any difference.
Because of this, and in so far linking (even statically) is done for interoperability, does not prejudices the legitimate interests of the rightholder and does not conflict with a normal exploitation of the covered program, it seems that the differentiation between strong and weak copyleft has few legal reality. In applying all relevant licences, the copyleft effect should target the copies and real derivative works, where a significant portion of the functional covered code has been copied, modified, extended etc. At the contrary and in most cases, it seems that in European law the fact of linking two programs and the technology used for it does not by itself produce a derivative work: viral licensing is just a ghost. It does not exist.
===
This article (from the same author) also goes into virality in EU:
https://joinup.ec.europa.eu/collection/eupl/news/copyleft-or...
=== (relevant snippets)
Although often highlighted by some free software lawyers, this notion of “strong copyleft” has never been recognized by case law. On 2 May 2012, the Court of Justice of the European Union ruled that a software licence cannot prohibit the legitimate licensee from reproducing the portions of covered code (for example, the APIs or data structures) that are necessary for interoperability and for linking the covered work with others that could be licensed differently. This was ruled in application of the Directive 91/250 EEC on the legal protection of computer programs.
[...]
At the contrary and in all cases, it seems that in European law the fact of linking two programs and the technology used for it (i.e. dynamic or static) does not by itself produce a derivative work. This is the reason why it was considered that adding copyleft licences like the LGPL or the MPL to the EUPL compatibility list was not more problematic than adding the GPLv3 or the AGPL.
===
It should be noted, however, that this hasn't been explicitly tested in court with open source software (the software case mentioned in the second article was between proprietary software developers).
Also in practice most projects aren't released in just the EU so the GPL's strong copyleft still holds true in US, for example, even for work done in the EU. But this isn't a concern for the European Commission since the EUPL was made for EU use.
https://joinup.ec.europa.eu/collection/eupl/news/why-viral-l...
=== (relevant snippet)
As a conclusion, it looks that in most cases, linking two programs or linking an existing software with your own work does not – at least in Europe – produce a derivative or extends the coverage of the linked software licence to your own work.
Such interfacing or linking escapes to the copyleft provision of any licence, open source (like the GPL) or proprietary. The technical way of linking for interoperability (static or dynamic, permanent or temporary reproduction of the needed code) should not make any difference.
Because of this, and in so far linking (even statically) is done for interoperability, does not prejudices the legitimate interests of the rightholder and does not conflict with a normal exploitation of the covered program, it seems that the differentiation between strong and weak copyleft has few legal reality. In applying all relevant licences, the copyleft effect should target the copies and real derivative works, where a significant portion of the functional covered code has been copied, modified, extended etc. At the contrary and in most cases, it seems that in European law the fact of linking two programs and the technology used for it does not by itself produce a derivative work: viral licensing is just a ghost. It does not exist.
===
This article (from the same author) also goes into virality in EU:
https://joinup.ec.europa.eu/collection/eupl/news/copyleft-or...
=== (relevant snippets)
Although often highlighted by some free software lawyers, this notion of “strong copyleft” has never been recognized by case law. On 2 May 2012, the Court of Justice of the European Union ruled that a software licence cannot prohibit the legitimate licensee from reproducing the portions of covered code (for example, the APIs or data structures) that are necessary for interoperability and for linking the covered work with others that could be licensed differently. This was ruled in application of the Directive 91/250 EEC on the legal protection of computer programs.
[...]
At the contrary and in all cases, it seems that in European law the fact of linking two programs and the technology used for it (i.e. dynamic or static) does not by itself produce a derivative work. This is the reason why it was considered that adding copyleft licences like the LGPL or the MPL to the EUPL compatibility list was not more problematic than adding the GPLv3 or the AGPL.
===
It should be noted, however, that this hasn't been explicitly tested in court with open source software (the software case mentioned in the second article was between proprietary software developers).
Also in practice most projects aren't released in just the EU so the GPL's strong copyleft still holds true in US, for example, even for work done in the EU. But this isn't a concern for the European Commission since the EUPL was made for EU use.
Yeah the sibling comment by j_san is likely more correct than what I wrote above
>It works much in the same way as AGPL
Interesting why dont current AGPL product adopt EUPL?
Interesting why dont current AGPL product adopt EUPL?
> It works much in the same way as AGPL
Interesting. Is this because of how distribution is defined to include "any act of providing access to [the Work's] essential functionalities at the disposal of any other natural or legal person"?
Interesting. Is this because of how distribution is defined to include "any act of providing access to [the Work's] essential functionalities at the disposal of any other natural or legal person"?
Yeah, I think the meat of it is how they define distribution
‘Distribution’ or ‘Communication’: any act of selling, giving, lending,
renting, distributing, communicating, transmitting, or otherwise making
available, online or offline, copies of the Work or providing access to its
essential functionalities at the disposal of any other natural or legal
person.The article says "The recent Commission study on the impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy showed that investment in open source leads on average to four times higher returns. "
Four times higher returns ... compared to what?
It's like an advertisement that says our product contains 30% less fat. 30% less than what? Than other leading brands? Than your previous formulation (and if so, how do we know you didn't artificially increase the amount of fat in said formulation, so it'd be easy to reduce)?
Four times higher returns ... compared to what?
It's like an advertisement that says our product contains 30% less fat. 30% less than what? Than other leading brands? Than your previous formulation (and if so, how do we know you didn't artificially increase the amount of fat in said formulation, so it'd be easy to reduce)?
The author of the study, Knut Blind of Fraunhofer, is a hardent proponent of software patents. If you read the study, you will find those nonsense things related to patents:
"Table 5.16: Impact of OSS Commits on patents on computer-implemented inventions (FE)"
"the number of national contributors to OSS has a positive influence on the development of patents on CII as an innovation indicator of the IT sector."
"Table 5.16: Impact of OSS Commits on patents on computer-implemented inventions (FE)"
"the number of national contributors to OSS has a positive influence on the development of patents on CII as an innovation indicator of the IT sector."
"a hardent" ? Do you mean "an ardent", or "a hardened", or a bit of both ?
t2s(1)
"EU Commission not satisfied with paying its developers below market rate, but instead would like them to work for free"
That's a weird interpretation of what is being said here...
From the rules[0] that are mentioned in the article:
> On 21 October 2020, the Commission adopted a new strategy on open source software1, encouraging the use of open source software by the Commission, the Commission's contribution to third-party open source projects and the sharing of Commission software as open source. In that Communication, it was stated that, wherever possible and appropriate, the Commission would share the source code for any computer programs where it holds the intellectual property rights on behalf of the Union.
But:
> This Decision should not create any obligation for Commission services to share Commission software under an open source licence nor any right for third parties to require Commission software to be made available under an open source licence. The Commission should remain free to decide whether to share Commission software or to license it under a proprietary licence.
[0] https://ec.europa.eu/transparency/documents-register/detail?...
From the rules[0] that are mentioned in the article:
> On 21 October 2020, the Commission adopted a new strategy on open source software1, encouraging the use of open source software by the Commission, the Commission's contribution to third-party open source projects and the sharing of Commission software as open source. In that Communication, it was stated that, wherever possible and appropriate, the Commission would share the source code for any computer programs where it holds the intellectual property rights on behalf of the Union.
But:
> This Decision should not create any obligation for Commission services to share Commission software under an open source licence nor any right for third parties to require Commission software to be made available under an open source licence. The Commission should remain free to decide whether to share Commission software or to license it under a proprietary licence.
[0] https://ec.europa.eu/transparency/documents-register/detail?...
Well, EU Commission hires indians via TCS or Infosys.
Rather that the Commission does not want to pay consultancy companies time and time again for the same code.
Oh, well, this is the opposite of how the European Commission works:
Managers climb higher in the hierarchy and get salary increase according to how high the budget they manage is.
There is therefore a consistent effort in all the units of all the Directorate Generals to ask budget for new projects, and find a plausible excuse about why an existing solution cannot be used, and a new solution needs to be built from scratch.
Then, once this is built, it is common practice to initiate a new project to throw away the solution and re-do it from scratch, again using an excuse reason like adapting to more modern technology, or providing better performance.
P.S. The European Commission is composed of 33 Directorate Generals (DGs), each of it responsible of a specific topic. One Directorate General, called DIGIT, is in charge of providing IT solutions to all the others. However, each Directorate General has its own IT department (called 'Unit'), developing solutions on its own, rather than using what is commonly available at DIGIT, or already created in other DGs' IT unit.
Managers climb higher in the hierarchy and get salary increase according to how high the budget they manage is.
There is therefore a consistent effort in all the units of all the Directorate Generals to ask budget for new projects, and find a plausible excuse about why an existing solution cannot be used, and a new solution needs to be built from scratch.
Then, once this is built, it is common practice to initiate a new project to throw away the solution and re-do it from scratch, again using an excuse reason like adapting to more modern technology, or providing better performance.
P.S. The European Commission is composed of 33 Directorate Generals (DGs), each of it responsible of a specific topic. One Directorate General, called DIGIT, is in charge of providing IT solutions to all the others. However, each Directorate General has its own IT department (called 'Unit'), developing solutions on its own, rather than using what is commonly available at DIGIT, or already created in other DGs' IT unit.
* the actual code that will be made public (in particular enabling all sorts of things to be built on top of the Commissions policy / legal know-how and rules)
* the signalling, encouragement and precedent that this provides to other public sector instances that may have been sitting on the fence, unsure or even oblivious to open source