Thursday, 2 August 2012

Turning into a gibbering idiot at interview...

I am really bad at interviews. Suddenly, my brain flips into a mode where I'm worrying about my potential answers will appear to each of the panelists and their competing opinions and interests, and while I'm making up my mind what's coming out of my mouth is a long stream of woolly waffle.

Asked what are the emerging trends in software engineering research that we ought to be teaching students, my brain runs at a mile a minute thinking the following:
  • Most of the things courses are struggling to adjust to -- cloud computing, platform as a service, polyglot programming, etc -- aren't "emerging", they've long since bloomin' well emerged. Some courses have even been struggling to get agile practices in there, and that's been around for ten years now.
  • Actually the bigger problem I see students having isn't the lack of "emerging research" on their course, it's that most of their studies are devoid of context and in software engineering context can change everything (the real-world problem we're trying to solve and all the real-world constraints on the team).  So they leave uni still strangers to many of the real problems of software development.
  • For your course? I'm not sure what to answer yet, because I'm still getting to know your teaching program. For ours, I know the problems the course I helped redesign had before my colleague and I redesigned it, which were...
  • The answer's probably going to be different for each of the students -- what are the paths your cohort of students tend to take? Do they try to form the next great start-up, go into big data, build safety-critical software for railway signalling?
  • And of course trying to think of what the favourite research topics of the panel might be.
Unfortunately, while it's thinking that (mostly thinking "would that be an ok answer?"), what's actually coming out of my mouth is a time-filling ramble, and I never quite say any of it.

Friday, 1 June 2012

Does Oracle v Google put a hole in the GPL?

I had an odd thought (a nagging worry) that with Oracle v Google's API argument resolved, there might be a gaping hole in the GPL, even version 3. I'm not a lawyer, so I hope someone will correct me on this and allay my concern. Let me tell it as a story....

One day, NastyCo decided it wanted to use nicelibrary in a proprietary software product. Nicelibrary is open source under GPLv3, but NastyCo don't want to give their source code away.

So NastyCo decide to use Maven to build their product. NastyCo don't give their customers a compiled binary; they give them a build script, and tell them "all you need to do is run the script; you can even just double click on it". When a customer runs that build script, their computer then fetches a compiled jar of NastyCo's code from NastyCo's servers, but fetches all the open source GPL libraries from Maven Central Repository and other public open source repositories. And their computer running the build script assembles the proprietary product automatically there and then.

Mr Nasty, CEO of NastyCo, reasons thusly:
  • NastyCo's proprietary source code isn't a "derived work" of nicelibrary because after Oracle v Google it seems to have been made clear that there's no copyright in an API.
  • The compiled and linked program together is a "derived work", but NastyCo are not distributing that -- they are just distributing the binary of their own code, and a build script. Their customers (running the build script) are fetching the rest from somewhere else and building the "derived work" themselves.
  • Because NastyCo aren't distributing ("propagating") a derived work, the GPL doesn't require them to publish their source code, so they're not in breach of the GPL.
  • Although the customers are running a derived work, they built it themselves (their computer built it using the build script), and the GPL explicitly allows them to run and modify private derived works, so they're not in breach of the GPL either.
  • Because those privately-run derived works are allowed under the GPL, NastyCo can't even get in trouble for condoning or enabling infringement.
So, thinks Mr Nasty, neither NastyCo nor their customers are breaching the GPL, but nicelibrary has now ended up in NastyCo's proprietary product that can end up on millions of customers' machines without NastyCo ever having to publish a line of sourcecode.

So, I dearly hope there is a flaw in Mr Nasty's reasoning, but what is it?