8 bits of news from recent times

Posted by ciaran on 0

There’s been plenty of good news in the last few weeks. Not enough to write full blog entries on, but here’s a list, newest first:

Update: And I should also mention that I’ve gotten fsfe.org/transcripts online with 33 transcripts so far of presentations on free software and how it interacts with software patents, software licences, and copyright.

— 
Ciarán O’Riordan,
Support free software: Join FSFE’s Fellowship

ISO won’t fast-track MS OOXML consideration

Posted by ciaran on 0

Background: OpenDocument format was approved as an ISO standard in May 2006. This was important for the free software community because there are free software applications for reading and writing OpenDocument files.

It was also good news because we could now ask governments to use this standard instead of existing proprietary formats. Most governments currently use Microsoft’s Word format, and while we have software to read and write that format, our software isn’t perfect, and it will never be perfect because we can’t see the specification of that format. As a counter-move, Microsoft then applied to have its format also approved as an ISO standard.

Recent events: Microsoft requested that their format approved by a "fast-track" procedure. The fast-track procedure is appropriate for applications which don’t contradict existing ISO standards. The Grokdoc website did a great job of examining Microsoft’s format and building a list of where it contradicts existing ISO standards. There were then efforts in many countries to inform national standards agencies of these contradictions so that they could raise these when responding in ISO’s discussion of the fast-track request.

This request was discussed by ISO and its national mirror committees on February 6th, and the request was rejected. So Microsoft’s application will follow the usual, more detailed process.

For more information:

For supporters of OpenDocument, we also have to learn from this process. We repeated some of the same mistakes made in the anti software patents campaign, and those were that we overloaded some people in the national standards bodies, and sometimes we were not well informed of what we were talking about. Here’s more information.

There’s no way to say what the right balance between making ourselves heard and holding back until we understand the issue is, but the general lesson to take from this is that we have to remember that the people we’re sending letters to are humans, and humans like short, on-topic communications.

— 
Ciarán O’Riordan,
Support free software: Join FSFE’s Fellowship

RMS transcript on Free Software and the Future of Freedom

Posted by ciaran on 0

Below is the table of contents for a transcript I just put online of a 2006 talk by Richard Stallman on "Free Software and the Future of Freedom".

Twenty years ago, someone made a transcript of a free software talk he gave in Stocholm. There are quite a lot of similarities between the 2006 version and 1986 version.

Here’s the 2006 transcript:

And here are the sections. Each item is a link to that section of the transcript:

Tivoisation explained – implementation and harms

Posted by ciaran on 0

(Translations: Deutsch)

To think about what free software licences should do about tivoisation, we have to understand what problems we’re trying to prevent, and how it works – so that we can ensure that it doesn’t work.

^How tivoisation works

Tivoisation is a technique that manufacturers use to produce a computer, to sell to you, whose software they can update but you can’t.

There are three elements involved in tivoisation:

  1. The manufacturer puts a chip in the computer which checks any software before it is run and which will only allow authorised software to be run.
  2. The chip can recognise authorised software by, for example, comparing a checksum (like a fingerprint) to a list of authorised checksums, or by checking for an encrypted signature.
  3. The manfucturer withholds the information which you would need in order to make software authorised.

By doing this, the manufacturer can still publish new versions of the software in the future. They just have to embed the encrypted signature in their new version, or send a remote command which would add the checksum of the new version to the list of authorised checksums.

However, if you try to use a modified version of the software, or try to run some third-party software, the computer will refuse to function fully, or will simply not run the software at all.

^Controlling your own computer

The name "tivoisation" comes from a computer called the Tivo which comes with the above restrictions (at least from Series2 models onwards). The Tivo contains spyware and blocks the copying of information even when you are legally allowed to copy that information.

The operating system installed on each Tivo is GNU+Linux, so if you buy a Tivo, you have access to the human modifiable source code and permission to modify it. But, if you try to use a modified kernel, the computer will not start. (As described in this article, midway in the 3rd paragraph.) So tivoisation prevents you from being able to use software that doesn’t contain spyware or wrongly imposed restrictions.

^Sustaining the free software movement

The second reason why free software licences should prohibit tivoisation is that tivoisation burns the environment in which free software flourishes.

Normally, when our software spreads, we gain more developers (individuals plus companies) as some of the users will know how to program, and they will make small or large changes. Also, many of the people who make changes will publish their improvements so that everyone, including the non-programmers, can benefit from the general ability of the community to modify the software. By making computers non-programmable, tivoisation makes free software users non-programmers.

So with tivoisation, the ability of the community to choose the direction the software develops in is inhibited, and the link between the spread of our software and the growth of our developer community is cut. If a million people bought Tivos, there would be an extra million GNU+Linux users in the World, and we would gain zero developers.

This is unfortunate to any degree, but it can also become particularly problematic if it becomes widespread.

If we accept this behaviour from hardware manufacturers, we will get more of it because hardware manufacturers have no reason to turn down the opportunity to have more power over their customers. If tivoised computers become the norm and the era of programmable computers fades into history, free software development and users’s control of their computers will be in trouble.

^What do we have to think about

While GPLv3 is being drafted, we have to think about how many different ways tivoisation can be done and whether or not there are ways that it can be done, or the same problems can be caused, that the current language could be improved to block.

Of the three components of tivoisation mentioned above, item #3 is the problematic one. If manufacturers implement elements #1 and #2, but told each customer the (possibly unique) encrypted signature, or how to add new checksums to the list of authorised checksums, then there would be no problem. The computer would only run authorised software, but you could decide what is authorised.

Indeed, allowing elements #1 and #2 is important because they can be used for security purposes. I could configure my computer to only run signed software, and then I could sign all the software on my computer. Then, if a virus ever modified the software on my computer or added a new program, it wouldn’t run. Or as a network administrator, I might also use this for multiple machines within one organisation. So elements #1 and #2 must not be inhibited by any method of blocking element #3.

^What discussion draft 2 of GPLv3 says

So, discussion draft 2 of GPLv3 blocks item #3 by saying that when you are required to distribute a program’s source code, you must include:

…any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use…

This only applies to people distributing hardware plus software where the hardware is configured as in step #1 above. If you are just distributing software, then the number of keys that are necessary to install and/or execute the software is zero. So this language only applies to a small number of hardware manufacturers, probably less than ten.

That sentence I’ve quoted is from the definitions of "Corresponding Source" in discussion draft 2 of GPLv3. Richard Stallman has said that in discussion draft 3, this will probably be moved out of that definition and into the section on distributing binaries.

Your comments on this issue are sought at the gplv3.fsf.org comments portal.

For more information about GPLv3, see FSFE’s GPLv3 project.

(I had help in writing this from the people on the fsfe-uk and fsfe-ie mailing lists. Those links point to the archive of the relevant discussions showing the people and their comments. Thanks. And thanks to Andreas K. Foerster for the German translation)

— 
Ciarán O’Riordan,
Support free software: Join FSFE’s Fellowship

GPLv3 embedded in devices

Posted by ciaran on 0

At last week’s GPLv3 conference, the topic of embedded GPLv3 software came up a few times. Below is something of a summary of those discussions. Georg Greve blogged about the conference, so I’ll avoid repeating what he covered. Suffice to say, it was an event the organisers can be proud of, and Tokyo is a lovely and interesting place.

I think the issue of GPLv3 in embedded software falls into two categories: warranties, and regulated hardware.

The warranties issue is quite simple. If a hardware vendor wants to say that installing modified software voids the warranty, that’s ok with GPLv3. GPLv3 says that if the software is modified, it must be able to interact with the same online services. Warranties are not an online service, so the warranty can be changed or voided when modified software is installed and that won’t violate GPLv3.

The more complex issue is with regulated devices such as mobile phones, wireless cards, voting machines, and medical devices. If a company decides to produce mobile phones, how can they use GPLv3’d software if they are required to prevent customers from transmitting or receiving signals outside of the permitted ranges?

With GPLv2, they could have built the phone to stop functioning if it detects that the software has been modified. This is what has become known as "tivoisation". This solves their regulatory problem, but it means that the GPL has not done its job of ensuring the recipient has the freedom to modify the software.

It may seem that these two goals are fundamentally incompatible, but they are not. A solution is that the phone manufacturer can put the part of the software which sets the signal transmission/reception into unmodifiable memory (ROM – read-only memory), and the remaining majority of the software can go in modifiable memory. Thus, the phone will not be used to break regulations, and the recipient has the freedom to modify most of the software, with the exception of the small part which it would have been illegal to modify anyway.

This is not immune to abuse. Phone manufacturers could put all of the software in unmodifiable memory. If they do this, we are no worse off, and no better off, than we are today. However, it seems more likely that they will opt to split the software between modifiable and unmodifiable, because that way.bugs can be fixed, and software updates can enable new services, etc.

So the deal is, if they want to retain the ability to modify the software, they have to let you modify it too. The second example of wifi cards is the exact same.

The third example is medical devices. This issue is quite similar, just with different hardware sizes. People have asked how certified medical devices could ever be allowed to have modifiable software.

Maybe it’s interesting to note that I haven’t heard of a medical devices manufacturer raise this issue. Maybe they know that this isn’t an issue. GPLv3 just prevents tivoisation. Do we have any evidence that current medical devices use tivoisation?

But that’s a side point. To answer the question directly, again the device manufacturer can use unmodifiable memory. Memory can be made unmodifiable by putting it into a ROM chip, but for medical devices, there is also the possibility of putting a lock on the box, and/or put the box in an area not accessible to non-certified people. I suspect that this is already the case and that even doctors and hospital IT departments do not have access to the firmware of X-ray machines etc.

And then the fourth example is voting machines. For this, the two key issues are when does distribution occur, and the difference between publication and supplying to the recipient.

If a government develops software for use on electronic voting machines, and if it produces a thousand voting machines and sends them to each region of the country, will the government have to give the source code, passwords and/or encryption keys to the staff at the voting centre? According to GPLv3, these things have to be made available to anyone you distribute the software to, but, according to copyright law, AFAIK, no distribution has occurred. This is just the government using the software on multiple machines. The government has not distributed copies of the software to the voting centres.

The second case is where a company develops the software and supplies it to the government. Here, distribution does occur between those two parties. However, the company only has to make the passwords and encryption keys available to the government. If the company has a second customer, it can set up the hardware to use different passwords or encryption keys. The government could event make a contract with the company saying that the company cannot give the passwords or encryption keys necessary for the government’s system to anyone else. Or further, the company can give the government (or any recipient) the ability to change what password or encryption keys are necessary. So even when distribution occurs, the use of DRM for security purposes is not restricted.

If there’s a case I didn’t cover, please email me: ciaran-at-fsfe-dot-org. And if you have a comment on the licence, please submit it to the gplv3.fsf.org comment system.

From the Tokyo event, here’s my explanation in other words.

There’s also a transcript of Richard Stallman’s talk from last week’s event.

— 
Ciarán O’Riordan,
Support free software: Join FSFE’s Fellowship

FSFE’s Freedom Task Force to make licensing easier

Posted by ciaran on 0

FSFE’s Freedom Task Force was announced on Monday …an announcement slightly overshadowed by SUN promising to GPL Java. What is FTF?

Shane Coughlan – our main FTF guy – will publish more information on this in the next few days, but there is an explanation here:

The idea is that the freedom of our developers, distributors, and users is protected by our licences. In our perfect world, we wouldn’t need licences, but we do. So that programmers can focus on programming, we’re going to try to make licensing as simple as possible by publishing educational info and by building a team of experts that can do this work.

How does this relate to gpl-violations.org? FSFE’s FTF will work with Harald Welte, and will try to reduce his licensing workload so that he can do more coding. We’ll be in close contact though – there are not many in the World with his knowledge and experience on GPL compliance.

How does this relate to FSF’s GPL compliance Lab? (who recently updated their webpage) The two are similar in that FSFE’s FTF will become another shoulder for the burden of bringing people into compliance with the GPL. To the extent that they will differ in method, FSFE’s FTF will probably focus more on the education side of GPL compliance, such as gathering best practices and publishing guides. Another difference is that we won’t only be working on GNU licences, we’ll also help free software projects that use other licences.

That’s the plan, and the direction FTF is starting in. Where it goes could depend on what needs arise and what people ask for help with. Shane’s contact details are on the webpage.

Sun’s choice of the GPL, and RMS in the webcast

Posted by ciaran on 0

Two positive aspects of choosing the GPL for Sun’s Java are that it is a copyleft licence, and that it means Sun’s project will be able to share code with the GNU Compiler for Java and GNU Classpath.

Sun have released under version 2 of the GPL, but have said that they will consider version 3 when it is finalised. Since GPLv3 should be compatible with the Apache licence, this would mean the above Java projects could also share code with the Apache Harmony project (which was launched and chose its licence after GNU Classpath and GCJ were working under the GPL).

Sun’s webcast announcement was made in a format that requires proprietary software, but the video will be made available in a free format in the near future. UPDATE: Ogg Theora videos are there now.

Richard Stallman is there in the webcast. Someone has re-encoded that file to a format that can be played with a free software video player: here it is

It’s only a minute, so here’s a transcript:

The GNU general public licence is the most popular and the most widely used software licence, used for some 70% of all free software packages. The special thing about this licence is that it’s a copyleft licence. That is to say, all versions of the program must carry this licence. So the freedoms that the GNU GPL gives to the users must reach all the users of the program, and that’s the purpose for which I wrote it. To ensure that all users of the software have the freedom that users should have.

I think Sun has, well, with this contribution, have contributed more than any other company to the free software community in the form of software. And it shows leadership. It’s an example that I hope others will follow.

UPDATE: Some people have asked how the developers of free software Java implementations feel about this. I heard from a GNU Classpath developer "boy are we happy hackers now!". Their positive comments can be read at http://planet.classpath.org/.

RMS, recently, on if SUN free Java

Posted by ciaran on 0

In a November 1st interview, Richard Stallman was asked for his thoughts on if Sun free Java (as they have done today). Below is a transcript of that section of the interview. The whole interview his at the following URL:

[50:35]

Interviewer: the last time we spoke, you mentioned two projects that you were very interested in. One was Gnash, the GNU flash, and the other was the open or free version of Java. It looks like SUN is really on the verge of releasing Java under a more open licence. What’s your opinion on that? Do you think it’s a good thing.

Richard Stallman: That’s the right thing to do. Of course. Everybody developing software should make it free software. If you’re distributing a copy of a program to someone else, you should do it in a way that respects his freedom.

SUN should have made Java free software before, but better late than never. If they made Java free software now, then they’ll be doing the right thing now, and I think that it’s more important that they do the right thing now than to reprove them for having done the wrong thing in the past.

Y’know, it’s more important to focus on correcting the problem than on complaining about it. So if SUN makes Java free, then I’ll say that there’s nothing wrong anymore.

Interviewer: And if SUN does go and make Java free, what’s that mean for the current project that’s in places for a free Java?

Richard Stallman: Well, we’ll have to see. There’d be no need for the goal of reimplementing Java for the sake of freedom, but some of the code that’s been developed may still be useful. And maybe we could start merging things, and so on.

But basically, if SUN’s Java implementation becomes free software, it will be a part of our community, and we would treat it like any other part of our community, based on what it is now, and not holding grudges on things that were wrong that were done in the past.

And meanwhile, the people who have worked on free Java implementations might be disappointed, but their work will not have been for naught. If SUN makes SUN’s Java platform free, we can be pretty sure that a large part of the reason for this is that people have been working on free java implementations. So they would be able to take part of the responsibility for the result.

[53:47]

— 
Ciarán O’Riordan,
Support free software: Join FSFE’s Fellowship

How GPLv3 Tackles Licence Proliferation

Posted by ciaran on 0

I wrote an editorial for LinuxDevices:

It’s meant as a discussion primer for what can be done in the GPL to remove reasons for people to write new licences, and to ease the problems created by new licences – such as licence incompatibility.

The third discussion draft is due out on November 23rd, or soon afterward, so getting comments in via gplv3.fsf.org in the next two weeks is a good idea.

Enjoy the weekend. I’ll see some Fellows at the first international Fellowship meeting tomorrow (Nov 11th, Italy).

What should GPLv3 do about MS and Novell?

Posted by ciaran on 0

While the deal is being analysed for GPLv2 compliance, it’s a useful example of a more general case worth thinking of regarding GPLv3.

The problem to be considered is: what if company A distributes some GPL’d software, and company B announces that they will not sue customers of company A. This creates a situation where some users are safe from patent litigation, and some are in danger – and company A now has an interest in sustaining or maximising that danger.

It’s probably safe to assume that this will only happen in cases where a business agreement exists between companies A and B.

The goal is that we wouldn’t want to discourage anyone from obtaining patent protection for all users of the software, but we mustn’t accept people stopping short of this in ways that give them a commercial advantage or an incentive to increase danger for others.

Some interesting details from the Novell/Microsoft issue are that Microsoft are not distributing any GPL’d software directly. They will instead be distributing coupons for Novell’s GNU+Linux distribution. Also, Novell are saying that the patent protection is not coming from them, instead it is coming from Microsoft direct to the users of Novell products.

Here’s what the current discussion draft says about patents: (from Section 11)

You receive the Program with a covenant from each author and conveyor of the Program, and of any material, conveyed under this License, on which the Program is based, that the covenanting party will not assert (or cause others to assert) any of the party’s essential patent claims in the material that the party conveyed, against you, arising from your exercise of rights under this License. If you convey a covered work, you similarly covenant to all recipients, including recipients of works based on the covered work, not to assert any of your essential patent claims in the covered work.

If you convey a covered work, knowingly relying on a non-sublicensable patent license that is not generally available to all, you must either (1) act to shield downstream users against the possible patent infringement claims from which your license protects you, or (2) ensure that anyone can copy the Corresponding Source of the covered work, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means.

Will that wording prevent companies making patent deals that shaft the free software community? What improvements should be made to that wording? Any suggestions, submit them to gplv3.fsf.org, and see FSFE’s GPLv3 page for more general information.

— 
Ciarán O’Riordan,
Support free software: Join FSFE’s Fellowship