Changes for me in 2009

(UPDATE: if you’re looking for me, try my homepage: http://ciaran.compsoc.com )

I look back on 2008 as a year of personal achievement. I worked hard at learning French and Dutch, and having passed various exams, I’m now studying for a law degree through French. The course involves a lot of work, and with exams in January, I had to make a very hard choice: after three and a half years with FSFE, I decided to not seek renewal of my contract for 2009.

My primary interest is still free software; legislation and policy in particular. In the long term, I think a formal degree in law will be very useful for this. This needs my attention in the short term, so I’m prioritising it now.

I’m proud of what I’ve done with FSFE, from fighting EU software patent legislation, through driving community participation in GPLv3, to helping to build the Fellowship community. I also feel I’ve had positive influences on general aspects of the organisation such as communication and legislative policy setting.

In turn, I’ve gotten to work with some very talented, very dedicated people. The staff and board of FSFE are people who really care about free software, and I continue to recommend that people donate to FSFE and join the Fellowship.

I see a sturdy future for FSFE and I’m happy that building the Fellowship community is a top priority. The two Fellowship seats on FSFE’s General Assembly is one sign of this, and the upcoming software overhaul of the Fellowship website (including a wiki) is another.

Community building is essential because knowledge, experience, and contacts must remain connected after any particular campaign ends. We can’t start from zero each time, and everyone needs a group that they can ask help of from time to time. By relying on the free software community for funding, the Fellowship is also an important way for FSFE to be as financially independent as possible.

But this isn’t a goodbye. I’m still active, just in a different and somewhat reduced capacity for a while.

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

Blogging thoughts

I always tell people to blog what they’re working on. "If it’s worth doing, it’s worth blogging!" I’ve put effort into blogging over the last three years, so here’s the advice that I give myself each time I start to blog something.

This entry is long and isn’t very well layed out, but it’s been on my laptop for too long so I decided to dump it out.

  1. Make the first paragraphs on-topic, and try to make them interesting. Everyone has a small number of writers whose articles they will read completely regardless of the topic, but for most people who see your blog, they’ll skim the initial paragraphs to see if you make sense and to see if the topic is of interest to them.
  2. When you read other people’s blogs and news articles, make a note of what you don’t like. Each time you stop reading an article or you get annoyed because some journalist is a moron, take a few seconds to make a note about why you stopped reading.
  3. Talk about the news, not about you. People care about how things affect them, or how they affect society, or how an effect displays a general principal. The inconvenience caused to you is usually not of much interest to others. If you’re looking for a topic to write about, look at what you’ve done recently (instead of looking at what news you found interesting and would like to give your opinion about). UPDATE Good example: someone just knocked on the door, collecting money "Hi, I’m doing a parachute jump for charity" – no, I’m not interested. And why would I be? If he told me what charity he’s supporting, there’s a chance I’d be interested, but if he’s just going to focus on himself doing a parachute jump, why should I be interested?
  4. It can take time. A good article-style blog entry can take six hours to write! Time is needed to develop the arguments, to dig up references and links, and to put the info in a right order and structure. You should know this, and employers should too. For some types of work, blogging should be given 20% of worktime. (Again, "If it’s worth doing, it’s worth blogging!")
  5. It can also be done quickly. You can post a scribble and add more details later. An example is my recent update about translating websites. It started off with two links, but after I posted it I remembered some more, and now it contains enough info to help someone.
  6. Don’t be a loudspeaker for your opponent. Use your first paragraph to make your point, not to repeat whatever they said. Further, don’t quote them directly if they use dishonest terms.
  7. Learn to paraphrase. Careful now. Paraphrasing is very different to putting words in someone else’s mouth! You can’t change the meaning of what they said. An example of paraphrasing is the "Motiviations" section of this entry about the Community Patent. In her actual words, she talked about a "patent infringer", but according to her story, the company had actually clearly never been in a position to infringe the patent and was only a potential infringer (if they crossed certain borders, if the patents were valid, if a judge would agree that the tyres infringed said patents, …). So it’s a good idea to retell her story, keeping the facts, but without repeating the mis-lable of "patent infringer".
  8. Who are you? Why should anyone read your writing? If your credentials in a field are not well known, then mention near the start what experience you’re writing from. If you’re the guy who installed some software, then write from that perspective.
  9. Blog, and you’ll improve with time. Always analyse afterward: was that a success? Is anyone reading? Will the reader have found it interesting enough that they’ll come back in a while to see if I’ve written anything new?
  10. Before publishing, read your own blog entry the way you’d read someone else’s. If you’re making an argument, then for each sentence, ask yourself "says who?" Not every sentence will need a reference, but it’s worth keeping in mind. If you’re just saying X is wrong, Y is good, people will find that boring and unconvincing.
  11. You have to publicise what you wrote – and if it was worth the time to write it, it’s worth a little bit extra to ensure some people read it. Some people think that to get published on community websites, they just have to publish their article, and if it’s good then readers and article scouts will submit it for republication on the community sites. That’s not how it works. Of the six times my work has gotten on Slashdot’s front page, five times were because I submitted it myself,[1, 2, 3, 4, 5] and once because someone else did.[6] Submitting your blog feed to aggregators is also a good idea. I’m on Planet ILUG and Planet Grep.be.
  12. If the blog entry is long (this entry is too long!), formatting is important so that readers can see at a glance what is in the block of text. Examples of three options are table of contents, or headings, or like in this post, bold text. The structure of this entry is not exemplary 🙂 but I might find time to improve it in the future.
  13. Read Richard Stallman. Aside from liking the political arguments of his writings, I find his style very disciplined. If he’s rebutting a disingenuous argument, he’ll paraphrase rather than repeating. He brings all arguments back to the values he’s working for (the value of software freedom). For example, to argue against software patents, one can say they restrict essential freedoms, and that they’re bad for small businesses. The latter is the easier argument to make, but Richard’s purpose isn’t the defense of small businesses, it’s the defense of software freedom, and he sticks to that purpose. Most of his writings are in the GNU philosophy directory and it’s worth reading transcripts of his speeches.

Ok, that’s all I can think of. I’ll add more as it comes to me. Regarding the first point, you have to keep in mind that a blog is not the same as a university assignment where the goal is to lay out your arguments, knowing that the one reader will be obliged to read from start to finish. Quite the opposite, the short attention span of web surfers is the main challenge of bloggers.

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

FSFE list for French-speakers

We’ve set up a francophone FSFE list:

This breaks our tradition of setting up public lists based on country or regional borders. Europe is complex and the boundaries that history has drawn are not always ideal for community forming.

So, if you know French-speaking people or communities in Belgium, Switzerland, Luxembourg, France, or anywhere else, please tell them about this new list.

The main risk with this approach is that the imbalance of population sizes will lead to the list being dominated by discussion of events in the largest region (France). To minimise this, we’ll make an effort to encourage membership of people from outside France.

(Yes, yes, "why are you announcing this in English??" – because that’s the language my blog is in!)

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

Update on gettext for static websites

I got some helpful responses to my HOWTO use gettext for static websites. Here are three systems, based on GNU gettext, for building translated static websites:

  • Políglota: the system used by getGNULinux.org. You can see how it works by looking at the source for that website. This tool takes care of updating internal links to translations too. (Thanks Gustavo Narea!)
  • xml2po – and some usage tips. Can either work with XHTML, DocBook, or your own custom written XML format. An XSLT can be used to generate the post-translation XHTML. (Thanks Goran Rakic!)
  • The new gnu.org translation system: GNUnited Nations. They say it currently can only work for gnu.org’s layout, but I guess a bit of hacking could make it work with other sites. The 0.1 release announcement has a little bit of other info.
  • Plus, although not based on gettext, the build system of fsfeurope.org is another way of managing translations. Most of the work is done by build.pl.

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

FSFE campaign: pdfreaders.org

pdfreaders.org is a website with info, graphics, and links about free software PDF readers. Websites shouldn’t recommend Adobe’s non-free reader, so we’ve made an alternative site they can link to.

The next Document Freedom Day is March 25th 2009, so it would be great to make a success of pdfreaders.org before then. You can help by asking website maintainers that link to Adobe’s website to link to pdfreaders.org instead.

The PDF format is both a de-facto standard and an officially recognised ISO standard, so there is no reason to endorse only one reader. Worse, in terms of protecting the rights of users, Adobe’s is probably the worst PDF reader to recommend. Adobe’s reader uses legal and technical measures to ensure that users cannot see what the software does, and cannot change the software’s behaviour.

The website is ready to use, but input from the community is greatly sought. In particular, we are probably missing information about free software PDF readers for non-free operating systems such as of Windows and MacOS. If you have past experience with this topic, feedback is welcome by email via feedback [at] pdfreaders.org.

Government bodies, educational institutions, and other non-profits should quickly understand the reasons to recommend the choice of readers at pdfreaders.org instead of Adobe’s PDF reader. This category of organisation should be the initial targets. In the mid- to long-term, possibly after the site is expanded and fine-tuned, this idea really should be appeal to all website maintainers.

With this, we hope to raise awareness of open standards and free software at the same time.

Translation help is also appreciated. To get started, there’s info and a mailing list on our translators webpage.

UPDATE: I forgot to mention GnuPDF. This is a software development project, completely unrelated to pdfreaders.org, but people interested in PDF and free software might find it interesting.

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

Fellowship seats on FSFE’s General Assembly

The General Assembly is the top decision making body of FSFE, and from the annual meeting of 2009 onward, the Fellows will have their own directly elected representation. This follows from a constitutional change adopted unanimously by those represented at this year’s GA meeting.

One will be elected in time for the 2009 GA meeting and a second will be elected approximately one year later. With each Fellowship representative serving a term of two years, there should be an election every year, and from the 2nd election onward, there should always be two Fellows in the GA. And they’re full members.

Fellows will get at least three month’s notice before any election takes place, and voting will use the Schulze method. Debian and other organisations have been using this method for a few years with no big complaints, so it seems to work very well.

The goal is to allow voters to express their preferences clearly, reducing the need or interest in tactical voting. i.e. If there are candidates A, B, and C. You like C, but everyone says C will never win. You prefer A over B. With commonly used electoral systems, if you vote for C, your vote is probably wasted. With the Schulze method, you can vote C-A-B, and if C doesn’t win, your preference for A over B will still be counted.

Fellows can vote as soon as they join. To be sure the candidates know how the Fellowship functions, we decided that candidates must already have been a Fellow for one year.

See our press release.

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

Gettext for static websites

Here’s how I implemented a translation management system for a static website, using GNU gettext. For the impatient, I’ve distilled it to 11 instructions at the end.

Goal

This system allows block-by-block translation (string-by-string), which is better than page-by-page because:

  • Changes to non-translated parts will be applied to all translations automatically (formatting, tags, images, maybe dates, names, links, etc.).
  • By storing the text blocks of all pages together, repeated blocks will only have to be translated once (menu text, copyright notices, headings, etc.).
  • You won’t get lost when the original changes while the translation is still in progress.
  • When you change a paragraph in the original, it’s easier to see what parts of the translations need to be updated.

For such a system, the abstract steps are:

  1. Somehow mark each translatable text block in your webpage. The non-translatable parts will become a shared frame.
  2. Extract the blocks into a database. Translate.
  3. Find or write some software to merge the blocks back into the frame to remake the original webpage – but with the option of taking the text blocks from either the English database or one of the translated versions of the database.

Gettext seemed like an obvious possibility, and everything’s working perfectly now, but it took me eight hours. The difficulty was that the existing documentation is all geared toward using gettext for computer programs, not for websites or documents. That’s when I realised that I must document what I did:

What I did

I started by minimally turning my webpage into a computer program. This involved five steps:

  1. Write a tiny program that prints some text (a string) into a file.
  2. Copy the webpage into the program in place of the string.
  3. Insert some standard bits of code required by gettext.
  4. Break the string into smaller strings, separating translatable from non-translatable
  5. Mark the translatable strings with gettexts’ tag (the format of the tags depend on which programming language you use but it’s usually something involving an underscore _ ).

Gettext works with lots of programming languages, so take your pick from the examples that come with the package. On my computer, these are in this folder:
/usr/share/doc/gettext-doc/examples/
The choice of language isn’t important. The code will be dead simple.

Here’s my original index.html:
<html><head><title>Cow</title></head><body><p>See also: <a href="http://fsfe.org/">FSFE</a></p></body></html>
Of the supported programming languages, I choose Scheme (a dialect of Lisp). At first glance, the code below looks complex, but you’ll only have to modify the first and third chunks. The first chunk defines three variables which should be self-explanatory. All the webpage text is in the third chunk. It’s broken up into blocks and I’ve put gettext tags for Scheme (_ ) around the translatable blocks. Here it is, generate-index.scm:
#!/usr/bin/guile -s!#(define output-filename "index.html")(define project-name "ciarans-website")(define build-directory "/home/ciaran/website-build/")

(use-modules (ice-9 format))(catch #t (lambda () (setlocale LC_ALL "")) (lambda args #f))(textdomain project-name)(bindtextdomain project-name build-directory)(define _ gettext)

(define page-text (string-append "<html><head>\n<title>"(_ "Cow") "</title>\n</head>\n<body>\n<p>"(_ "See also: ")   "<a href=\"http://fsfe.org/\">"(_ "FSFE")   "</a></p>\n"   "</body></html>\n\n"))

(define the-file (open-file output-filename "w"))(display page-text the-file)
Three of the eight strings are marked as translatable. The other five are part of the shared frame that will be the same no matter what language version of the page is being generated.

Remember to replace any quote marks in your HTML with backslash-quote (\"), and to add a few line breaks (\n) to make the output readable. Those are the quote and the newline sequences for Scheme. They’re the same in a few other languages, but they’re different in others.

Before you continue, you must set the “build-directory” variable to the directory where generate-index.scm is. If you don’t, everything will seem to work but your program will never access the translated strings.

That done, you extract the translatable strings with these two commands:

  • $ xgettext --language=scheme -d ciarans-website -k_ generate-index.scm
  • $ mv ciarans-website.po ciarans-website.pot

And then you can create a file (a “po” file) for French translations with this command:

  • $ msginit --locale=fr

One part of the gettext manual says that “msginit” is optional – that you can do it manually instead, but this didn’t work for me at all. I spent two hours diagnosing that problem. Use msginit.

This creates fr.po which you can edit with any text editor. There will be a line at the top like this:

"Content-Type: text/plain; charset=UTF-8\n"

If your charset is “ASCII”, you should probably change it to UTF-8. If your charset is something else and you get error messages from other gettext tools (such as msgmerge) about invalid characters, then changing charset to UTF-8 might also be the answer. There’ll also be a field for content-transfer-encoding. The manual says that should always be “8bit”.

Emacs is particularly good for editing po files because it has a special editing mode for them.

Next you have to convert your po file into the special mo format and put it in the subdirectory where gettext expects it to be with these two commands:

  • $ mkdir -p fr/LC_MESSAGES
  • $ msgfmt --output-file=fr/LC_MESSAGES/ciarans-website.mo fr.po

Make the Scheme file executable, and that’s it!
ciaran@hide:~/tests/simple-page$ LANGUAGE=fr ./generate-index.scm; cat index.html

<html><head><title>Vache</title></head><body><p>Voir aussi : <a href="http://fsfe.org/">La FSFE</a></p></body></html>

ciaran@hide:~/tests/simple-page$ LANGUAGE=en ./generate-index.scm; cat index.html<html><head><title>Cow</title></head><body><p>See also: <a href="http://fsfe.org/">FSFE</a></p></body></html>

ciaran@hide:~/tests/simple-page$
Ok, so there’s your proof-of-concept. Next, I have to convert my site to this system and maintain it (using msgmerge). I’ll try to keep notes to publish here. Lastly, thanks to the ILUG community, who suggested some alternatives.

The instructions

  1. Make an empty file generate-index.scm
  2. Copy my generate-index.scm (above) into your file
  3. Adjust the build-directory (3rd defined variable) in generate-index.scm to point to the directory where your generate-index.scm is
  4. $ xgettext --language=scheme -d ciarans-website -k_ generate-index.scm
  5. $ mv ciarans-website.po ciarans-website.pot
  6. $ msginit --locale=fr
  7. edit fr.po to add translations of the three text strings
  8. $ mkdir -p fr/LC_MESSAGES
  9. $ msgfmt --output-file=fr/LC_MESSAGES/ciarans-website.mo fr.po
  10. $ chmod +x generate-index.scm
  11. $ LANGUAGE=fr ./generate-index.scm; cat index.html

UPDATE: (2008-12-15) Some nice people sent me info about existing systems, so I’ve put that info in a recent blog post.


Submit to FSDaily
Ciarán O’Riordan, (RSS)
Support free software: Join FSFE’s Fellowship

Status of FSFE’s legal dept: FTF

Inside FSFE, we talk a lot about our legal department, the FTF. I was in the Zurich office a while ago with the FTF’s coordinator, Shane Coughlan, and took the opportunity to gather some info for anyone interested.

The FTF works in five main areas:

  1. Building a European legal network
  2. Producing documentation
  3. GPL enforcement
  4. FLA agreement for copyright management
  5. Training and consultation

Legal network

For two years now, Shane’s been building this network of lawyers and licence experts which now includes 145 members. Three quarters of the members are lawyers. The others are experts in company policy, licences, or technical aspects of licence enforcement. About 120 come from Europe, and the others are spread across The Philippines, Japan, Singapore, China, Taiwan, South Korea, Australia, Canada, and the USA.

I think most network members support FSFE’s work. I know others don’t, and that’s ok. Whether we share a vision for the future or not, everyone has to obey the GPL, so it’s useful for free software licence compliance specialists to talk with each other and share best practices. Most discussion is about the GPL, but we talk about all free software licences.

Other topics such as software patents and antitrust are also discussed.

FTF organised Europe’s first free software legal conference in Amsterdam in April with 53 members of the legal network attending – 5 coming from outside of Europe. Feedback from the attendees was very positive, so there’ll certainly be more such conferences in the mid-term future.

Producing documentation

Some of the documentation produced by FTF is already online – there’s a documentation section on the website. One type is the documents Shane produces, such as the useful tips for users of GPL, and same for vendors of GPL’d software.

Another type is the documents that the network members pass around among themselves. These are usually procedures, guidelines and other documents that have existed for a long time internally in their various companies. If these documents cannot be published, then at least by circulating them privately in the network, they can expand the knowledge of many free software lawyers. In the long term, some of these documents might become publishable or, if allowed by the author(s), will be used for the basis of our own documents.

GPL enforcement

This is the quietest part of FTF’s work. We don’t go to court, and we don’t go to Slashdot. (Update: Hi Slashdot) Compliance is gotten while maintaining relations with the distributor. Of course, we also work with gpl-violations.org, which does take people to court. We’ve been working with them since FTF started in 2006, and earlier this year we agreed to deepen that relationship. And to reduce problems originating from the manufacturers, the "for users" and "for vendors" useful tips have been translated and distributed in Chinese and Korean (they’re temporarily offline during a webpage reorganisation).

FLA: Fiduciary Licence Agreement

The Fiduciary Licence Agreement is used when a developer wants to grant an organisation the ability to enforce the licence of the code, and give them the ability to update the licence of the code – with the limit that the new licence must also be a free software licence. The developer doesn’t lose their copyright, so they can also enforce and change the licence of their code, without limits.

This is important for legal maintainability of a project. If a problem is discovered with the licence, having a central body maintaining the copyright would allow the project to avoid the difficulty of find all past authors and getting unanimous agreement on what changes to make to the licence. A big recent success is that KDE announced that they’re going to use it. More good news is that it should soon be in 10 languages. FSFE has become the legal guardian for a small number of projects, such as OpenSwarm and Bacula, but that’s not our focus for the FLA.

Training and consulation

Lastly, Shane visits companies or regions to deliver training courses on free software licences and legal issues. A skeleton course is online on the SELF platform: The strategic implementation of Free Software in business.

These courses are educational for legal experts dealing with free software, and they’re also a way for the FTF to be financially sustainable. If you work for a company that has a legal department and that deals with free software, you can help the FTF by suggesting to your boss that they get Shane to deliver a course. With so many big companies profiting from free software, and with the FTF providing value to so many lawyers for free, it’s only right that the costs of the FTF be covered by these companies rather than the income we get from the community (through the Fellowship). Another significant source of funding for which we’re grateful is NLnet.

Ok. That’s what I see the FTF doing. If you read this far, I hope I answered some questions!

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

Recent fellowship meetings (Autumn 2008)

Recent fellowship meetings (Autumn 2008)

In the last two months, I’ve been to Fellowship meetings in The Netherlands, Germany, Switzerland, Belgium, and Ireland. These usually happen whenever I have another reason to go to a city. We organise a Fellowship meeting to make the trip it extra worthwhile.

One purpose is to get to know the interested people in an area: it’s much easier to work with someone that’ve you’ve met face-to-face. They also provide another way to get feedback and for people to get in contact with FSFE. We also discussion specific topics such as planned upcoming campaigns or things that are happening in that country or region.

One thing I’ve heard at a few meetings is that there is a lack of awareness of who is active in each country. Sometimes a department would switch to free software, or a CD of free software would be given to every student, or a free software article would appear in a non-technical magazine, or a politician would acknowledge free software in a speech, but it’s not clear who made this happen. (This was also mentioned by Rolf Camps in the last Fellowship interview.)

The next Fellowship meeting is planned for Brussels, Sunday November 9th. We always email the Fellows in a country about upcoming meetings, so being a Fellow is the most reliable way to know when something is happening in your country. We also usually mention them on one of our mailing lists and on our events page. These are all also good ways to know what’s going on in your area. And there’s also the general discussion mailing list.

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

FSFE’s antitrust victory with Samba

FSFE’s role in the antitrust case was to ensure that free software developers would be able to use any interoperability information that Microsoft would be forced to publish. After 5 years of work, the last court case was won last year. There were always doubts about whether Microsoft could really be pinned down, but from Samba developer Andrew Bartlet’s blog, it seems the Samba team are now loving the interoperability information.

I didn’t do much on this case. For FSFE, it was mostly Georg Greve and Carlo Piana. This work involved filing briefs, court appearances, backing up the good parts of the European Commission’s work in the press, acting as advisors during meetings, etc. A partial list starts halfway down our antitrust project page. Generally not very visible work – they’re not the sort of meetings you can blog about when you leave. From Samba, they worked with Andrew Tridgell, Jeremy Allison, and Volker Lendecke – who were each very capable in the court rooms.

There were other organisations involved, but FSFE played two key roles.

First, we represented the interests of free software developers. Others had interests such as the ability of their private company to compete with MS, or lowering the price of X or Y, or fining MS, etc. These organisations were on our side, but they could have accepted a solution that excluded free software. FSFE was there to constantly argue that free software must benefit from the outcome, and to explain what this required.

The second key role was persistency. The case began with many companies bringing evidence against Microsoft, but one-by-one they made business deals with Microsoft and withdrew from the case. This could never happen to FSFE, so FSFE was a reminder that the European Commission would never be left alone on this case.

There are two other organisations worth mentioning. SIIA is the only other organisation that, like FSFE, stayed in the case from start to finish. And ECIS is worth a mention because although they joined late, they added a lot of strength to what we were supporting.

The antitrust case was sometimes misunderstood. The mainstream media – with its love of simplifying topics down to numbers – constantly reported about how much Microsoft were going to get fined. That’s a pity. The fines were never important for us. Helping Samba and other free software projects was the important part. Done.

Some interesting links

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