Ade makes some interesting points about the GPL, particularly the opportunity to exclude certain jurisdictions where the use of the software would infringe a patent. He also raises the question of whether distribution of source code – as opposed to binaries – can be counted as infringement and reflects on the trend to explicitly claim for a medium containing code that would cause the invention to be ‘realised’ on a computer.

Background

If you’d like an elegant and (generally) very well argued primer and history of what can be patented in UK law see this judgement (from 2006, things have changed a bit since then). The judge in that case, Peter Prescott, was actually only standing in and therefore wasn’t really expected to take a fresh look at it as he did and go against patent office practice that had been making software patents a bit easier to obtain in the UK up until that point.

He’s something of a personal hero of mine

Why I’m writing about this

I guess the first thing to say is that I’m no patent lawyer, this is not legal advice and my knowledge is limited to UK and (a little) to EU patent law. The knowledge I have was gained through working as a patent examiner (one of the people who decides whether or not a patent is granted on an idea) from 2004-2007 at the UK Intellectual Property Office. During the last year of my time there I was in the department working on ‘unpatentable’ inventions: software patents, business methods and the like.

This area of patent law moves quite fast in varied, contradictory and nonsensical directions and I really have not been paying attention to it since I left almost three years ago.

Who can infringe? (Why claim the software medium?)

Within UK law, at least, there is the idea of primary and secondary infringement. The primary infringer is someone who does something directly reading on to the claims of a patent. So if the patent claims only the method of doing something and your software performs that method when run then the primary infringement would occur only when the method is actually performed (i.e. when the program is run). In that scenario, if you were selling the software then only your customer would be a primary infringer when they used the software. However, as a supplier of the means to infringe, you could be open to a claim of secondary infringement. The original logic of this was – I believe – to allow the owner of a patent to sue, say, the British importer of an infringing device rather than having to pursue a foreign manufacturer abroad.

However, pursuing a case for primary infringement is easier and so, as Ade noted, many patent applications will also include a claim along the lines of:

A storage medium containing code that, when run on a computer, performs the method of claim x

This would allow them to go after anyone supplying the program on a disc as a primary infringer.

There was, briefly (I think it got overturned) a court judgement in the UK that ruled that any claim to a program on some kind of medium was a software patent as such (well, obviously…) and not permissible under UK law. I had great fun in my last few months as a patent examiner rejecting loads of applications simply by saying:

Claim x is a claim to a computer program on a storage medium. The invention is therefore clearly a computer program as such and cannot be patented.

Applicants and their patent attorneys didn’t much like that.

So does source code infringe?

I doubt it. There may be an argument for secondary infringement, but that gets in to all kinds of difficulties as there are various defences such as the research defence (pure academic research and the publication of methods arising from it are immune from patent infringement) or freedom of speech (anyone remember the haikus containing the deCSS code?).

Also few people make money from distributing source code, so where’s the point in suing them? It’s easier to sue the end user who directly infringes (and doable if they’re a big company: SCO tried it with Daimler, albeit in a copyright rather than patent case) or someone distributing the binaries on a commercial basis (if the patent owner remembered to claim for software discs too).

Disclaimer: as far as I’m aware, the above has never been tested and a lot of it might not apply outside the UK anyway.

Why does this matter to KDE?

Most of the software patents that came to me originated in the US and were fairly easy to dismiss under UK law. However, there was a patent application that came to me before I worked in the unpatentable section that could have had a direct impact on Amarok.

I don’t remember the details of the patent in question (and probably couldn’t reveal them anyway as I don’t want to mess with the Official Secrets Act). However, it was for a hardware audio player and one of the features it claimed had, I knew, been in Amarok for a little under a year, but before the filing date of the patent. It was my opinion that Amarok would have infringed had the patent application been granted. It took me a couple of days to find the disclosure of the feature in the Amarok infrastructure (trawling wiki page histories and forum posts), twice as long as the target time allotted for processing that particular patent – and I had to hit that target to get promoted.

The point is that the Amarok wiki and forums are not somewhere we routinely searched for prior art and had that patent application been passed to someone else who didn’t know (or care) that the feature was already in Amarok then the prior art probably would not have been found. I would not have been criticised for not finding it and it was against my interests (other than as a user of Amarok) to spend the time doing so.

The problem is more than software patents

As illustrated by the Amarok case, it’s not only software patents that can be dangerous. The ‘invention’ there was obvious – to you or me – but it probably wouldn’t have been patently obvious, by which I mean the the level of invention required for getting a patent is low.

There is also a problem not only with a lack of time to do things properly, but also a lack of technical knowledge. I examined applications concerning JIT compilation, despite having no knowledge of programming. I examined applications for magnetic hard drive read heads without having the faintest idea of what would be obvious to someone in the industry, or really even really which features were important.

I always had the impression, since we saw the results of prior art searches from other offices, that the European Patent Office were far more thorough than we were. They certainly had more time per patent application and found things in places we would never have looked. We tried not to look at what the US Patent Office was up to.

I’ll finish off by quoting Peter Prescott in that judgment I linked to at the start:

Despite the prohibition on granting patents for computer programs … it is said that the EPO [European Patent Office] has granted more than 40,000 of them… From the point of view of the applicants … if there is any chance of getting such a patent it may be said to be a rational business choice to try it. If not, their competitors might … patents that are wrongly granted can be very expensive to challenge, and perhaps beyond the means or inclination of small and medium enterprises. An accumulation of patents of that sort … may be a serious barrier to entry.

The only safeguard against that wrong – and it is a wrong – is the vigilance of the Patent Office. When I was a Patent Office examiner … we sometimes granted patents that we shouldn’t, but did it anyway because we thought the Patents Appeal Tribunal would not support us.

I spent the last couple of days attending a “results-based writing” course hosted by my university. The main aim was to learn some things about writing concisely for scientific papers and finding a good structure for my thesis, but the lessons are applicable to all many kinds of writing. Writing a thesis takes a lot of endurance and strong writing ability, as you have to keep the reader interested and informed for thousands upon thousands of words encompassing complex topics and formed scientific opinion. While many online education sources do indeed offer some great tips on compiling a good thesis paper, it is best to take a look into face to face courses as well as you can ask questions of the teacher and other students and involve yourself verbally as it plays out.

The training I attended was provided by Cognitrix and was excellent. These are key points that I took away from the course:

• Know your audience
• Identify the concepts and how they link
• Don’t try and hide uncertainty with vague language
• See the opposite point of view
• Cut the waffle
• If you can’t say a sentence in one go then it is too long

They maight seem obvious, but many scientific papers fail on a lot of them. More detail on each follows below.

Know your audience

What jargon can you include? What explanation is necessary? On the Dot I insert hyperlinks to applications, jargon or concepts that I think might not be widely known, but mostly base that on what I understand.

Identify the concepts and how they link

We took a science paper, wrote its concepts out on paper and drew arrows to link them. Those with the most outgoing links are probably good starting points; those with mostly incoming links conclusions. Some items were not linked at all (these were mostly irrelevant and could be removed). Others had few links coming in and needed more background.

Don’t try and hide uncertainty with vague language

I know I’ve tried this in the past when I haven’t quite understood something. Not on the Dot, because there are far too many knowledgeable people reading and I’d get found out If you can’t explain something well then you probably don’t understand it properly yourself.

Try and imagine the opposite point of view

Particularly useful for science. Scrutinize statements like “it is obvious” to see whether they are true. Do you need to provide justification?

Cut the waffle

Some of us (I am guilty) can be a bit verbose. Being brutal with every word, we cut a sentence from 50 to 19 words with no loss of information.

If you can’t say a sentence in one go then it is too long

If you can’t remember at the end of a sentence how it started then the information is hard to take in. A good test is whether you can say the sentence aloud without pausing for breath.

Summary

Applying some of the above, I just cut the length of this post by 21%. I’m going to be trying to apply these lessons not just in my dayjob but also in my work with KDE. So you should read a bit less from me

Guidelines for application release articles

The result of that discussion is in the advice on the Dot article submission page and set out in the guidelines on the wiki. Since not everyone visits every page on the wiki all the time, here’s the most pertinent part of that guidance:

We cover, as much as possible, all feature releases of anything but very rarely development/maintenance releases except:

• The software compilation (devel and maintenance)
• First new platform ports (devel)
• Really exciting new features (devel)
• Significant new application (devel)
• “Maintenance” releases which DO include new features (e.g. Amarok, sometimes)

Of course, we take many other articles other than application release announcements and the general guidance on the Dot submission page covers them.

Is this a change in policy?

Possibly. In the past this hasn’t really been well defined, resulting in some inconsistency – for example turning down articles about beta releases of an application for which we’ve previously reported beta release. It’s more a case of defining a policy rather than changing an existing one.

Why?

It comes back to the question of who the Dot is for. It really serves two main audiences:

1. Contributors to and users of KDE software
2. The wider tech press (a lot of Dot stories get picked up elsewhere)

Group 1 covers a range from casual users to early adopters, beta testers and developers. Some of these (early adopters to developers) are going to be interested in development releases. However, most of these probably also read the planet and/or the relevant mailing lists.

Group 2 generally don’t report on development or maintenance releases for individual applications (with certain exceptions)

So, group 1 probably don’t need development releases on the Dot to know about them; group 2 probably don’t really care.

Proper maintenance releases without new features should go largely unnoticed by users – so they don’t really need to know about them until they appear as distro updates.

Exceptions

With regard to development releases, there can be more general interest in particular cases. First, the software compilation is bigger news because it is a lot of stuff (and lots of new features). Second, first development ports to Platform 4 are more interesting since some people are really wanting those (e.g. K3B and Kaffeine).

With regard to maintenance releases, the exceptions are when some horrific bug is fixed or, again, the software compilation where there are going to be a lot of bugfixes.

We’re unlikely to want to carry articles where the interesting point is that it is a new development or bugfix release, but where there is an interesting story and the release is incidental (such as in the examples above) then of course it could be interesting to carry it.

Summary

Hopefully that helps explain the new guidelines and putting this on the Planet makes a few more people aware than having it on the Dot submission page or the wiki alone. Comments and questions are welcome and if you’re not sure about an article idea you can always send an email to dot-editors@kde.org asking for our opinion before you spend time writing something.

Well here it is: If you used to use “KDE” don’t just replace it with “KDE SC”

At least, not always… I’ve noticed a few people – and even your KDE Promo team is not immune from this – apparently being a little confused about what terms to use. People are trying to be good and not use “KDE” alone but in some instances this leads to a little overuse of KDE SC when that’s not really what is meant.

Be Happy, by Ana Cotta (CC-by)

We want KDE SC to be usefull for everyone in the world. So, do our icons and our terms work for everyone in the world?

So, what’s wrong with that? Not necessarily anything. The question is, does he really mean we want only the SC to be useful for everyone in the world? We’ll never do a usability survey for Amarok icons? So perhaps the better term would be “KDE software” rather than “KDE SC”.

Björn’s post is a case in point because the error (if any) is very small and subtle, but there are a few other examples I’ve seen that do appear to show more confusion. I won’t pick on anyone here, but here are a few examples of sentences using old and new terminologies to show that we don’t want to just replace “KDE” with “KDE SC”:

Old: “I use KDE”
New: “I use KDE software” or “I use KDE SC (4.4)” or “I use KDE Plasma Desktop (4.4)”

Use whichever one you really mean.

Old: “KDE is great – just look at how cool Digikam is”
New: “KDE software is great – just look at how cool digiKam is” or “KDE (community) is great – they made digiKam”

Just think – are you talking about the community or the software?

Old: “KDE is the best, it has Kontact, cool widgets and desktop effects”
New: “KDE software is the best – for example Kontact, the Plasma Desktop widgets and desktop effects” or “Plasma Desktop is the best – you have all those cool widgets and desktop effects” or “KDE Software Compilation is the best – it comes with all the Plasma Desktop widgets and effects and great apps like Kontact”

Old: “I want to make an app, should I use KDE or Gnome or plain Qt?”
New: “I want to make an app, should I use the KDE Platform, or Gnome or plain Qt?”

Old: “KDE 4 sucks and I’m switching to Gnome until there’s a KDE 4 K3B”
New: “KDE SC 4 sucks, I can’t even get a KDE Platform 4 version of K3B to fit in with it, Gnome forever” or “KDE Platform 4 sucks, no K3B yet, Vista for me” or “Plasma Desktop 4 sucks, there isn’t even a complementary version of K3B. I’m going back to CDE.”

See, you can even use the right terms when trolling

Old: “Nepomuk is one of the most exciting developments in KDE 4″
New ” Nepomuk is one of the most exciting parts of the KDE Platform 4″ or “Nepomuk is one of the most interesing things in KDE SC 4″

Old: “Amarok is an awesome KDE app”
New: “Amarok is an awesome KDE app”

Some things change, but some things stay the same

So, this is really an internal thing – perhaps you post to the Planet or write about KDE elsewhere. If so, and you support our efforts at clarifying our branding, please try and think about what it is you mean and use the right terms. If we simply replace “KDE” with “KDE SC” then we won’t have achieved anything. We don’t want KDE SC used everywhere, if we did we’d have given it a catchier name

There is, as always, more to do. Nathan Ogden has done some really great work (with assistance from others on KDE-Promo) putting together a guide for distros on how to use our brands in their communication. We need to get the word on that out to our distro contacts (something I should be helping with – perhaps you can help?) so that it’s as easy as possible for us all to work together and present things in a consistent way.

Any other examples? Queries about the above? “I hate the rebranding” rants? Please post below

Why do this?

So, a lot of that text is not mine (although I endorse it fully – it’s only not mine because I didn’t manage to describe things that well). One of the things I did do was put together that diagram of the brand map for the Dot article. After doing that, I wondered how it looked under the old branding structure – well, you can see the results below (old brand names first, new ones below). Hopefully that indicates how the old branding structure has been ambiguous and made it really difficult for us to present the products in any kind of coherent way.

Old brand map

New brand map

It was messy and a lot of those KDE/KDE 4 names were used interchangeably (and often we still had K Desktop Environment too). Writing anything quickly became a mess of KDEs and you could only tell from the context – and some prior knowledge about what we do – what each of them actually meant. The new brands make my job a lot easier and if we make the job of promoting KDE products easier then we should get better promotion of KDE products. Of course, it is also desirable to split the Plasma Desktop and Plasma Netbook from the apps a little so that people not running one of those should not be put off trying out Amarok, KOffice or K3B.