EU Commission to open source software
ec.europa.eu
ec.europa.eu
* 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
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.
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.
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.
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).
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).
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.
Why would you want them to get into that? It doesn't seem like it's something appropriate for a government to get into.
That's the slogan of https://publiccode.eu
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 :)
https://ec.europa.eu/isa2/actions/open-source-software-editi...
Git and Markdown would do a better job, XML is insane.
Legal text is not prose, it does have structure and metadata attached to it.
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).
https://ec.europa.eu/info/news/eu-fossa-bug-bounties-full-fo...
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
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);
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"?
‘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.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].
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.
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."
Interesting why dont current AGPL product adopt EUPL?
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.
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)?
"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."
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.
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?...