jump to navigation

Are algorithms copyrightable ? December 4, 2006

Posted by Imran Ghory in Copyright, Software development.

(disclaimer: I am not a lawyer, this article is personal opinion)

If I was asked a few days ago “can an algorithm be copyrighted ?”, I would have replied with the canned answer “no, of course not, copyright protects the expression of an idea, not the idea that’s expressed.”

However since reading Hart & Fazzani’s Intellectual Property Law (part of the Palgrave law series). I was no longer convinced so I decided to google to see if anyone else had discussed it. But other than the canned answer I gave above I couldn’t find any firm evidence supporting the uncopyrightable status of algorithms. And during my searches I found the submission policy of ACM Algorithms which clearly indicates that they at least believe some algorithms to be copyrightable.

Generally speaking if you translate a program from one programming language to another then you have to have permission from the original author of the program (in the same way you would need permission to translate a book from say English into Spanish). The Palgrave book specifically gives the example of translating from FORTRAN to COBOL as being a type of “adaptation” that requires permission. In Canada Apple Computer Inc v Mackintosh Computers Ltd. came to a similar conclusions.

So why should translating an algorithm from pseudo-code into an programming language be any different, I’m sure most implementations of binary search are based on text-book pseudo-code rather than derivation from first-principles.

The obvious counter-response for this has been that if an idea can only be expressed in one form then it’s not copyrightable. However in the UK at least this doesn’t appear to be true if the idea is sufficiently complex. In the case Ibcos Computers Ltd v Barclays Mercantile Highland Finance Ltd (1994) which is one of the most important software copyright cases in the UK it was decided that “copyright cannot prevent the copying of a mere general idea but can protect the copying of a detailed idea” and this is a decision which has been referred to and affirmed in a number of court cases since that time.

And “detailed idea” is a concept which will almost certainly apply to most modern algorithms. As far as I know no-one’s ever taken an algorithm copyright case to court (possibly because such court cases over algorithms have traditionally been in the US where patent law can be applied instead of copyright), but it could just be a matter of time before it happens and possibly opens up a huge can of worms.

The Geek Doesn’t Wear Prada November 29, 2006

Posted by Imran Ghory in job interviews, recruitment, Software development.

It’s a rare occurrence to find geeks debating fashion and what to wear, but that’s what happened a few days ago when thedailywtf ran a story about job interviews

Most of the participants fell into one of two camps, the “pro-suits” and the “anti-suits”. The pro-suits generally took the opinion that “a job interview is a formal event and as such not dressing formally would be inappropriate and disrespectful” . The anti-suit camp generally fell into “developers should be judged on skill alone, after all what developer wears a suit anyway ?”

Sadly both camps missed the point completely. There is no “golden bullet”. There is no definite answer about what you should wear to a job interview. Different companies have different cultures, different countries even more so.

The single most important factor to consider when deciding what to wear is what other interview candidates will wear. When you meet meet your interviewer for the first time they’ll be comparing you to every other candidate they’ve seen. And if there’s anything about you that’s significantly different from everyone else that’s what’s going to stick in their mind as their first impression of you. Not your skills, not your lovely personality, but what you’re wearing.

If you’re the only candidate who’s turned up in a suit or a t-shirt you’ll be remembered as “the suit guy” or the “the t-shirt guy”, not because the interviewer disapproves of your dress sense (although they may do), but simply because that’s how human memory works.

The key point I’m making is that you don’t want to be remembered for what you wearing, you want to be remembered for being “the Boost wizard” or “the smalltalk guy” or at least something that has some relevance to the job.

Of course if you’ve just been called for an interview you may have no-idea what other candidates have worn in the past. But it doesn’t harm to ask, HR or your contact at the firm will almost certainly be willing to tell you what the dress code is both for day-to-day work and for the interview. Or if you’re reluctant to ask them then ask around, ask your friends what they would wear for an interview at that company.

But if you’re really stuck then I’d suggest dressing over-smartly. There are far more companies that will reject you for looking “unprofessional” then there are companies that will reject you for being “too smart”. Plus it’s a lot easier to take off a tie and undo your top button to become more casual then it is to make t-shirt and jeans look professional

Google code search: A vulnerability hunters dream October 7, 2006

Posted by Imran Ghory in Computer Security, Google, Software development.
1 comment so far

Google code search: A vulnerability hunters dream? – well maybe not, but if a hacker wants to compromise random machines rather then particular targets then Google’s making finding new exploits ever easier.

Google’s latest search tool has made it incredibly easy to take one particular vulnerability which has a fairly recognizable signature and search vasts amounts of code for it. And to prove it here are some examples:

(Some of these are derivative of various suggestions posted on reddit)

For starters lets have a look for programs that run setuid/setgid and copy strings from environment variables without even verifying the lengths (hence providing an easy buffer overflow exploit):

In a similar vain code that takes an environment variable passed to it by a web-browser before sticking it in an SQL query (thus allowing SQL query injection attacks):

How about code which uses the unsafe chmod command ( chmod is bad due to non-atomicity, code normally checks the file has some properties first before chmoding it – however due to the fact that the checking is a separate operation from the chmoding a hacker could replace the file with a symlink after the check but before the file has been chmod – hence allowing them to change the permissions on arbitrary files) :

Or a similar race condition which can be used to create havoc, this time the mktemp() function – which creates a temporary file with a predictable name (so what happens if someone else gets there first with a symlink….).

I think the scariest so far is the number of mid-to-large size projects which show up for this following search (where an input is read from a file into a fixed size buffer without a limit being put on the amount of data being read in):

And somewhat more lightheartedly a look at all the programmers that are hard-core traditionalists when it comes to crypto:

So there you have it – vulnerabilities galore and just from a few minutes work.