Appetisers, prior art and patents

Over the last year I’ve read many articles about how software patents are bad and evil and whatnot. Most of them give an example of a big evil company (often Microsoft) applying for some obvious patent and them laughing their heads about how incredibly stupid the whole thing is.

The problem is that most of these people do not understand how legal documents work. They read the brief and think, oh, wow, I could have thought of that!

BTW: I am not a lawyer and this doesn’t constitute as legal advice.

The brief is not the whole document

Briefs are not meant to cover the entire claim. That’s what the patent claim does. Instead, the brief just gives a short, general idea of the claim. Patents are not accepted, rejected or prosecuted on based on the brief.

Think of the brief as the appetiser in a meal. If all you have is an appetiser, you’re not going to get very full.

In other words, a brief is just that, brief.

Patents are all about implementation

If the patent applicant finds a novel way of doing something commonplace, they can still apply for a patent. Prior art doesn’t work if the methodology is completely different; likewise, you can’t sue someone if the method they used was completely different.

In other words, just because the idea is obvious doesn’t mean the method is also obvious.

If it’s mentioned in the patent, chances are it’s different

If you see the prior art you were thinking of acknowledged or mentioned in the patent, then that usually means that the applicant recognises that that art does something functionally related to the patent, however they still think that it’s different enough to warrant a patent.

To name one that has recently popped up in the geek news: In patent 7,617,530 (Rights elevator), the applicants specifically mention sudo as a prior art for process escalation, however consider the patent to be different.

Consider the patent in full

Finding prior art for some of the patent does not invalidate the entire thing. If it did, we could stop someone getting a patent for a tire engineered to grip tighter on pavements using a specific method with “prior art: tire.”

Conversely, just because someone got a patent on a tire engineered to grip tighter on pavements using a specific method does not mean someone just patented a tire. Patents cover the entire implementation; one can’t be sued for just making a tire using this patent.

Legal language is not English

Patents are not written so that normal people can understand them; they’re written so that lawyers can understand them. Think of programming in BASIC – the language is based on English, but is extremely strict, and someone may find it confusing if they have no prior training. Similarly, legal language may be confusing to those not doctrined to the strict meaning of words in legal language.

Above all, READ THE PATENT IN FULL. Do not EVER go on just the brief alone. Seriously. It can save you a lot of trouble, and stop you from looking reeeally stupid.

Hope this clears up some confusion!
--MarkKB

OpenCity vs. “Microzoft”: Why Are Linux Developers Jerks?

OpenCity is an awesoem free city simulation that I came across back in 2007, but since I moved to Windows Vista, I haven’t been able to run it.

OK, let me backtrack a little. I have been an avid Linux fan since 2001, when I ran a Red Hat 7 box. But one of the things that’s always bugged me is the attitudes of some people. Don’t get me wrong, it’s not everyone, but even one sour response can spoil the broth, so to speak.

There’s a long story behind my usage of OpenCity on Windows Vista, however I’m not going to tell it right now, seeing as it’s, well, long.

Anyway, I decided to try to run OpenCity again recently. No problem: go to the website, download the install binaries.

And then I saw this:

Please note that Windows platform is a secondary target. It's mainly because Microzoft[sic] doesn't support OpenGL correctly. Blame Microzoft not us !

Sigh.

There are two things wrong with this statement:

• It’s fine if Windows is a secondary platform and you don’t/can’t devote resources to it. What’s not fine is blaming Microsoft for the fact. Microsoft didn’t make you not care.
• OpenGL is supported just fine on Windows. Microsoft provides a bare minimum base ICD (like most of its’ drivers), and expects the manufacturer to provide its’ own ICD, as it knows how to properly support OpenGL best.
• Oh, and there seems to be something wrong with your “s” key; it keeps randomly generating “z”s. :D

Now, I could put this down as simply being misinformed. The OpenCity development team may be repeating common “knowledge” that has been parroted without checking. But then there’s this:

In case where OpenCity doesn't start under Vista, blame Microzoft again, not us ! We've worked hard to make OpenCity as portable as possible but Microzoft always tries to make open source developer's life harder and harder.

I’m sure Microsoft employees have nothing better to do than dream up ways to make your porting attempts fail. I can just hear them now: “Hmm, how can we annoy those OpenCity guys today?” “I know, lets break their build again!”

Seriously, you need to step back and examine what you just said. You said Microsoft is always looking for ways to stop you from making Windows apps (albeit free/open source and/or ported from Linux.) In other words, they are trying to stop people from using Windows.

It doesn’t matter whether the software is FOSS or not – its’ still Windows software, and while because a program is on Linux and Windows may not make someone buy Windows (though it probably will influence them in that direction), not having a favourite program on the platform may mean loss of a customer.

Microsoft simply doesn’t care what philosophy your app has, as long as you use Windows to run it. That’s the simple truth.

It’s important as a developer that you be as unbiased in your code as you can, because, in the end, the customer does not care what the specifics are. They will, however, care that your application doesn’t work, and, rightfully so, they will complain to you. If you must work around some OS bug, so be it, but remember, you chose to build for that platform.

(And no, OpenCity still doesn’t work. :( )

UAC is not (that) broken in Windows 7

Note 25-11-2011: I initially planned to pair this post with another post discussing the flipside – that injection-based attacks still pose a risk, and it would be better for Microsoft to have left the default at the maximum setting, and force the user to use a Standard account. Since Leo Davidson (the discoverer of the flaw) replied below, I also intended to post a response to his reply – however, both got sidelined and forgotten. This post is left here intact for historical purposes.

A few days back, Long Zheng (who has my upmost respect as a blogger) published (another) article about UAC. Before we discuss that, let’s summarise the article linked at the top of his, written by Microsoft’s Mark Russinovich:

• UAC was made primarily to make life easier for standard users. Ergo, standard users could use Vista with relative ease, as opposed to, you know, pretty much not at all.
  • It does so by using a split token – users would run in standard mode, and get a prompt to elevate when needing admin privs.
  • In this way, people could set up an admin account for big swabs of admin fun, while using standard accounts normally without having to switch to the admin account for e.g. installing stuff.
• Many people were complaining that they still had to get great swabs of prompts to elevate to admin while they were using an admin account. Still others complained about redundant and unneeded prompts.
  • Microsoft responded to this by cutting down on multiple prompts and removing unnecessary prompts.
  • They also added a security token to some programs that will make those programs autoelevate some tasks in admin mode. That way, admins can do their great swabs of admin stuff without getting a prompt every minute or so. Pre-emptive comment: that was an exaggeration to make a point. I know their must be something seriously wrong with my computer to get a prompt a minute.
• UAC is not a security boundary. In the end, it is up to the user to decide whether or not to run that program.

Zheng’s primary point of contention is that programs will inject code into other programs to elevate themselves to avoid the hassle of doing it themselves. This ignores several things:

• It is actually harder to inject code into another service than to set up an elevated COM interface (or autoelevate your program.)
• People doing this are just begging for their programs to be broken in the next release of Windows.
• It is unlikely that any major software developer is going to do this, since they usually submit their programs through WHQL, which are sure to pick up on this practice.
• Programs can do this anyway – that is, piggyback on some other programs’ UAC prompt using injected code. Once someone else's code is running, “your system” isn’t *your* system anymore.
• If you’re a virus writer, it’s easier to tell your users to elevate first than to go through the hassle of code injection.
• Finally, standard user will still get the prompt. If you are running as admin, you either a) should know what you’re doing, or b) shouldn’t be admin in the first place.

I’ve also seen some people claim that this allows Microsoft to parrot “make your programs UACified” without doing it themselves. Er, no, because they still have to make it work in standard user. The whole admin thing is to make it easier to set up your computer, then set up a standard account.

Having said all that, I do think Microsoft is making a mistake, and I for one will be pushing the UAC bar all the way to eleven. However, treating it as some inherent flaw in UAC is missing the whole point, which was to run as standard user without switching accounts.

As an added bonus, Rafael Rivera (who I also have a lot of respect for) asks why the icon is a shield if it’s not protecting users. I can think of a few reasons:

• Its use steams from the Security Center in Windows XP which was (shock horror!) a shield. Although Security Center is no longer in Windows 7 (replaced by the Action Center), the icon remains for non-confusion.
• (submitted by Bad Analogy Guy:) Like a proper shield, it’s up to the bearer to decide whether or not to hold it up or down. However, knights don’t wear shields when they’re hunting, nor do lords when they’re beating up peasants *ahem*, making proclamations and laws and whatnot, because they can be reasonably sure that they’d be safe.
• Marketing and programmers don’t talk very well to each other.

Have a great day, I’ll be here all week. Try the veal.

--MarkKB

The State of Audio on Linux Part 1 – Insufficient Memory

Note 26-09-2012: I was going to do a series of articles on the sordid state of Linux Audio as it was in 2009, but as with a lot of things, this got sidetracked and forgotten. This post remains for historical purposes.

My memory sucks.

Yesterday, I was talking with Jonathan (a friend) about Linux on the Desktop, and I remembered something I had read half-a-year previous about the state of audio on Linux. I couldn’t remember what it was, only that it involved mixing – I put it down to the inability to do hardware mixing.

This was the article I read. Oops. ^///^

For those not willing to RTFA, it talks about the history of Linux audio. First there was OSS. Then OSS became proprietary (teh EVILS!), and then the free version of OSS got old, so ALSA was built to replace it. Unfortunately, ALSA was completely incompatible with OSS, so they had to include emulation to support both older apps and people who didn’t want to learn ALSA. But the emulation wasn’t all that good in that it doesn’t do software mixing, which defeats the purpose of using ALSA in the first place.

So, to sum up, ALSA doesn’t do software mixing for its OSS compat stuff. My bad.

OK, so how is Audio on Desktop Linux really? Stay tuned!

--MarkKB