Karsten on Free Software

Yesterday, the European Commission finally published the new version of the European Interoperability Framework [pdf] [link updated]. We at FSFE have been working on this document for a long time. When it was published yesterday, we gave it a welcome despite some reservations.

Glyn Moody points out a number of weak spots in the new document. Actually, I’m concerned about many of the same points as he is. Still, I don’t agree with his judgement that EIFv2 is a “great defeat”. The document would certainly have been a lot worse without the hard work of FSFE and others. Even though it leaves some key issues open, it represents some progress.

Whether to welcome EIFv2 or not is a question of what you take as a baseline for comparison, and if you view the document isolated or in context. A lot will also depend on how the EIF is implemented.

But let’s take the issues in turn.

The baseline

What do we compare EIFv2 to? Compared to the original EIF from 2004,  which we’ve now uploaded to FSFE’s website for reference, it’s certainly a letdown. However, compared to the drafts we had to raise the alarm about during the process that created EIFv2, it’s quite a lot better. A year ago we saw a draft that said

“it is also true that interoperability can be obtained without openness, for example via homogeneity of the ICT systems”

and many other nonsensical formulations that would have left the document entirely meaningless.
So the content of EIFv2 is not as strong as that of EIFv1. There are also various loopholes (or rather barn doors) that would allow governments and public bodies to pretty much ignore the EIF,  if this document was just standing on its own.

EIFv2 in context

That’s where it becomes important to view the EIF versions in context.

EIFv1, good as it was, was just a recommendation by an expert group somewhere in the innards of the Commission. It didn’t have any official status. That’s why it was possible for this document to contain such strong statements.

EIFv2, on the other hand is an official communication by the Commission. That makes it a binding policy document, rather than something that member states and the EC itself can ignore at their leisure. That status also explains why there was so much fighting about it, both outside and within the Commission.

Then there’s the fact that EIFv2 needs to be read together with other documents. There’s the eGovernment Action Plan [pdf], which defines some concrete actions that the EC and member states will take by certain deadlines. The plan says that “Member States are fully committed to the political priorities of the Malmö Declaration” (p. 15).

This declaration from 2009 makes it a political priority for EU members to

“[p]ay particular attention to the benefits resulting from the use of open specifications”, and “ensure that open specifications are promoted in our national interoperability frameworks in order to lower barriers to the market” (paragraph 21). It goes on to state that “the Open Source model could be promoted for use in eGovernment projects”

and that

“it is important to create a level playing field where competition can take place in order to ensure best value for money.”

The eGovernment Action plan also states that by 2013, member states

“should have aligned their national interoperability framework to the EIF” (p. 13).

So now member states actually have to do something. That wasn’t the case with EIFv1.

Open Standards, FRAND, and implementation

Then there’s the issue of what, exactly, the EIF says an Open Standard is. The definition in EIFv1 was pretty good. The definition in EIFv2 is less good, but again it’s better than it was in the intermediate drafts, where it sometimes was simply missing.

Most importantly, EIFv2 clarifies that Open Standards (or “open specifications”, as the EC has decided to name them) must be implementable in Free Software, while explicitely allowing for FRAND licensing — as long as it’s compatible with Free Software.

The question is what, exactly, the Commission and the member states will do with this clause. As Glyn Moody argues, they can drink the BSA’s Kool-Aid and use standards that are impossible to implement under copyleft licenses like the GPL, due to their attached FRAND conditions.

They can also take this to mean that even where a standard comes with FRAND conditions, it must be implementable in copyleft Free Software. There may be some ways to achieve this. Some people argue that royalty-free is simply FRAND with zero licensing fees.  That’s a pretty roundabout way of saying “royalty-free”, but it could work here. Or one could discard running royalties (ie.  patent licensing fees paid for every copy that’s made of a program) in favour of a one-time payment.
The EIF’s formulation here is not a nicely balanced compromise.  It’s a smoking crater in the middle of a battlefield where many more shots will yet be fired. We will observe very closely and take the appropriate action.

Conclusion

So what we have now is a strategy statement, without the level of detail that made EIFv1 such a useful document. But this strategy generally goes in the right direction, and it’s much more powerful than before, thanks to its official status.
I’m guessing that the change we’ll see across Europe will be slow, but that it will be continuous and very broad. EIFv1 provided a rallying point for those member states and public bodies that were interested in Free Software and Open Standards. EIFv2 is a general push for everyone to use more Open Standards, even though it contains generous get-out clauses.

On the whole, we welcome EIFv2. It’s not everything we wished for, but it’s far better than we feared. We’ll watch its implementation very carefully, and will nudge it along where necessary.