I made it back to Auckland from NZNOG this evening. We drove to Wellington and back to save on airfares seeing as there were four of us attending. The drive didn’t seem quite as long as I thought it would. It took about 7 hours from Hamilton to Wellington and vice versa, although the roadworks every 5 kilometres from Cambridge to Bulls were getting very tedious.

Without a doubt the most interesting part of the drive was seeing some activity around the vicinity of Palmerston North where there were trenchers and tractors and some big loops of blue fibre lying on the ground. Very nice to know that progress if finally being made!

The remainder of the conference was also very positive. During the conference dinner on Thursday night we talked to many people about the idea of setting up a NZ routeviews project. There seems to be lots of enthusiasm for it, so hopefully we’ll be able to get something underway promptly.

I also did a very short lightening talk on dhcparpd. The software that we used to spoof ARP replies based on the DHCP lease database at LCA. Its a very nifty little utility and we’re hoping some more people will find some use for it. I’ve written up a page with some information which you can find in the WAND research software repository.

NZNOG’06 is currently on at Victoria University in Wellington and we’ve been down here since late Tuesday.

Wellington must have the most dismal and disgusting weather in New Zealand. Since we arrived, I don’t think we’ve seen the sun at all, and its been raining almost continuously. Gray, dark and dismal.

The conference started yesterday with the tutorial day. Dean Pemberton and Joe Abley’s tutorial - “IPv6 Deployment - Theory and Practice” was well attended and very useful. They started off with a brief refresher on the basics of IPv6 before starting to deal with some of the issues that are preventing more widespread adoption and finishing with a great audience discussion about why we even need IPv6 at all.

The two key points that I got out of it were:

• We don’t have any real pressing driver for IPv6 deployment at the moment, other than we all want it as geeks. The only real justification that anyone could come up with for a NZ organisation to deploy IPv6 is future proofing - that is gaining experience so that once we actually find a reason to use it we already know how.
• Many people see the lack of ability to multi-home as a significant problem preventing IPv6 deployment by organisations. Its not a problem for carriers, they can multihome just as they do not, it’s a problem for organisations like universities that don’t resell connections, but have a desire for multihoming. The point that Joe made was that there is no technical reason why you can’t multihome with IPv6. The lack of ability to multihome as an end-site is based no policy, and that policy was designed and implemented by the proponents of IPv6. Once the carriers and others who are still happy on v4 start to migrate to v6 its entirely possible that we’ll see some of these policies loosened as people ignore the policy and start multihoming anyway.

The conference network has been handing out v6 addresses with native connectivity provided by TCL. Kinda nifty, but again, I’ve got an IPv6 address to play with, I can look at the dancing turtle, now what…
The rest of the program is looking interesting as well, lots of talks on peering this morning and an intruiging talk by Bill Woodcock from PCH about building global content distribution networks (basically anycast for TCP).

I promised that I would post again stating how I thought NZOSS should respond to the SSC legal guide. Instead I got caught up helping Peter actually draft the response.

I was only involved in the first few drafts before I had to turn back to real work, however Peter and many of the other NZOSS participants finished off the document. I think the final product is slightly more verbose and touches on more points that I would have raised personally, but I do think it sets the right tone overall and certainly won’t do us any harm.

This seems to have been justified by the news today the the SSC has offered to fly two representatives of the NZOSS down to Wellington on Friday to meet and discuss the document. I would have liked to have gone, but given that I’m going to be attending NZNOG for most of next week I don’t think I can really justify the time off work.

It would be good to link to the actual response itself about here, but as far as I’m aware its not up on the NZOSS website yet. There is an earlier draft at http://www.devcentre.org/ssc-response-legal-guide-oss-2006-03-08.pdf which is very close to the final in content. I think only grammar and minor formatting was changed after this point.

Now we sit back and wait to see what the SSC will do after the discussion on Friday. All in all I think this whole episode has underscored how healthy the level of open source support within the NZ government is.

There has been a lot of rhetoric lately about broadband in New Zealand, from the Prime Ministers statements in the opening speech to Parliament, through to the Campbell Live edition dedicated to the state of NZ broadband. It’s encouraging that the poor state of broadband in NZ has become a high profile issue.

It’s also encouraging to see that ISPs such as iHug actually have a reasonable strategy to present to the Government about how things should work.

I think its becoming clear that Telecom’s arrogance has met its end and there are some fairly serious changes on the horizon. I’m hearing a lot of people saying that it’s no longer a question fo whether the Government will proceed with LLU, but whether they will force a structural split of Telecom in addition to LLU.

Personally, I’m not going to be making any predictions in public yet, the Government has talked tough and not followed through before, but the signs are definitely looking positive for hearing some good news later in the year.

The State Services Commission (SSC) (the NZ government body that oversees NZ government departments) released a guide to legal issues in using Open Source Software recently. The publication of this guide has caused a certain amount of consternation in the open source community and even manged to make it to Slashdot and Groklaw as well as spawning a fairly active thread on the NZ Open Source Society’s openchat mailing list.

Through all of this I’ve found myself very much on the opposite side of opinion to most other people commenting on it. My initial thoughts on the document are quite nicely summarised by the Groklaw comment that Stuart points out. While the document uses some unfortunate language, there is nothing in it that is actually untrue. In fact my initial feelings towards the document (without having read it thoroughly) were that it was good to see the SSC taking enough notice of open source to feel the need to advise departments on the particular issues that it can bring up.

Particularly dissapointing to me are the conspiracy theories that have been flying around. Groklaw surmises that the paper is a Microsoft hatchet job simply because it was authored by Chapman Tripp (a large NZ law firm) who happen to also represent Microsoft NZ on a range of intellectual property issues. I’ve yet to hear a single shred of evidence to back up this assertion and I find it quite ridiculous. Large firms working in a small market such as NZ will often run into conflict of interest issues and have well established procedures for dealing with them. Without seeing evidence to the contrary I cannot accept that a reputable firm like Chapman Tripp would risk their reputation by trying to intentionally mislead the goverment in a report like this. A far more like scenario, to my mind, is simply that the author(s) of the report are not very familiar with open source issues and didn’t do quite as much research as they should have to bring themselves up to speed with the unique IP features of open source licenses.

Having read the document more thoroughly now, I can agree that it is far from perfect. I think the single most glaring problem is that it focusses only on open source software and doesn’t mention that many of the risks also exist when using proprietary software. This could leave an uneducated reader completely scared off open source due to a mistaken belief that it is far too risky. On the other hand we shouldn’t completely dismiss the document either as it does raise a number of clear risks that a department will face in adding open source software to their IT environment. We’re not going to do ourselves any favours by pretending that open source is a panacea to all the worlds software ills and can just be dropped in to any IT environment to make things better!

It’s worth pointing out at this point that previous evidence from the SSC indicates that they are open source friendly. They have a very clear policy stating that Departments are encouraged to consider open source software alongside proprietary software and use it in cases where it wins on the basis of cost, functionality, interoperability, and security.

Given this history, I am alarmed at the hostile reactions many participants on the NZOSS open-chat mailing list had to the document. Quite frankly I think some people are responding far too emotively to the language in the document (which is problematic - but not that bad) and missing the chance to evaluate the rest of it in an objective manner. We have a SSC that has indicated a friendliness towards open source in the past, and I don’t think that they would turn around and reverse their position in this manner. This report is intended to support their overall policy after all. Rather than jumping down their throats and shouting about how poor the document is we need to engage in a civil dialog, point out the issues with the document and offer constructive suggestions for how the document can be improved.

To that end, Peter Harrisson has started some pages on the NZOSS wiki where we are going to co-ordinate our impressions and responses to the document so we can present a consistent NZOSS position to the SSC in response. I’d encourage everyone with an interest in the document to read and contribute to those pages.

As for exactly what I form our response should take and what it should consist of?

I’ll follow up with another post on that later in the weekend when I’ve had a bit more time to reflect.
What I do know (if you haven’t guessed already) is that I think we should be very careful not to respond in a hostile and emotive manner that will result in our relationship with the SSC becoming worse. That means we should take time to consider the document objectively, evaluate its propositions and provide a well researched and substantiated list of suggested improvements to the SSC.