The low-down on open-source law

An interview with Brendan Scott, the founder and head of the Open Source Law legal practice and Web portal; a firm dedicated to helping organizations use FOSS to better the long term value of their ICT expenditure.

Brendan Scott is a Sydney-based lawyer specializing in communications and information technology. After almost a decade of experience working in large law firms, Scott established and heads the Open Source Law legal practice and Web portal to help organizations, particularly in the public sector, use FOSS to better the long term value of their ICT expenditure.

According to its corporate profile, Open Source Law provides services in all aspects of ICT-related law. Most of OSL's clients have an open source connection, but not all of its work is strictly open source related. The practice also advises on ICT procurement, including development and systems integration projects, business related drafting, IP ownership and distribution agreements.

Here, Computerworld chats with Scott about the growing impact free and open source software is having on Australian government, businesses and enterprise, and what can be done to fuel and facilitate that growth.

Is your business increasing due to the growth of open source software adoption in enterprise and large organizations?

Business is good. I have noticed an increase in cold calls I am receiving for open source issues. At a broader level there has been marked growth in the Australian industry and therefore in the pool of users it is servicing.

In your experience, are there any common themes affecting the decision to deploy open source or proprietary software? And what should be considered in a good open source policy?

The question about themes is difficult to answer because it all depends on how the enterprise is dealing with the software. If they are a bare user they have a different profile from if they are customizing an application, to if they are on-supplying the software, to if they are on-supplying with modifications.

Let me make a few short comments on the "bare users" and suppliers:

From a user's perspective, the licensing requirements have minimal impact. FOSS allows users enormous flexibility in their deployment. They are not subject, for example, to artificial limits on the configuration of the implementation, the type of hardware on which the software is installed, or on the number of users. To add 10 or 100 copies of a FOSS product has no extra licensing fees. Users do not need to wait to negotiate a contract. If they need the software to be customized they can do this. Even if the licensing fees were not zero, FOSS still gives cost benefits because of this flexibility.

Rather, open source issues for users are more subtle. Open source is about community. You need to understand the community to operate effectively in it and this means changing your own behavior. For example, if you start a new job and there is a cake morning on Monday, then you are going to have to find a cake shop or hone your baking skills if you want to be part of the team. Popping out for group coffee on a Friday like you did at your last employer won't work. That is why it's important to connect with people who are already members of the community and know their way around it - people from the Monday set, not the Friday set. For example, one of the risks I have identified for my clients is in getting support from the community. The lodgement of a bug report or a support request from a work address can inadvertently disclose confidential information to the world. That is the sort of thing a good open source policy will cover. Unless you're in the community and understand how it operates you're not going to be alive to those sorts of risks.

The case for suppliers is quite different. Licensing issues for suppliers can be very simple or very complex depending on the circumstances. The flexibility of open source licensing gives suppliers great flexibility in creating and delivering solutions and this means there are interesting legal issues to be resolved. For example, a lot of my clients are implementing "software as a service" models enabled by open source components. Because of the licensing flexibility they can also offer hybrid models where their clients get to pick and choose what bits are hosted and what bits are installed at the client's premises. I help them put together terms and conditions which anticipate this complexity.

Do you have an idea of how many Australian enterprises have a formal policy in place regarding open source software?

Not enough. Several years ago I wrote a short paper called "The Open Source Legal Landscape". It highlights that open source enters an organization through different pathways to closed source. Typically these pathways are not subject to management review (for example, because there is no "purchase" involved) and are therefore largely invisible. The first part of managing open source usage within an organization is understanding and regulating these pathways. The second part is to educate the users about responsible FOSS use. You need a policy to address these (and other issues). For the reasons I outlined above you should have someone from the "Monday set" helping you with your policy.

Where do the most significant or prevalent legal implications stem from regarding the use of open source software in enterprise?

Open source provides flexibility in implementing solutions, so you can be much more creative with your problem solving. Therefore the legals need to be a creative as well. You also need to interface with existing (closed source) licences to ensure you're going to get the cost savings you thought you were getting. This means being proactive about your open source strategy so you can renegotiate your closed source licences in time to get savings. For example, if you pay a flat fee for whole-of-organization licensing then replacing half of your closed source with open source won't give you any cost reduction. You will need to negotiate a change to the licensing at a renewal ahead of time (e.g. to change it to give a proportional discount based on the number of copies installed)

So open source issues in enterprise are about understanding and implementing a long term strategy for the adoption of open source. Existing enterprises have spent 20 years under a closed model and the idiosyncrasies of its licensing have become embedded in IT practices and expectations. One of my clients was setting policy for open access to certain categories of data across Australia. I worked with them and we discovered this meant that there needed to be the ability to extend and modify existing tools. This in turn meant that the APIs for those tools needed to be licensed in a broad way not only today, but the APIs needed to be protected against closure in the future. I negotiated API licences from their suppliers and now organizations around Australia are taking the benefits of open data sets and open APIs for the toolsets.

The piecemeal substitution of some open source components will give some savings, but you need to take care that your closed source vendor does not simply use the next version of their software to shift the lock-in to a different level in the tool chain.

How have Australian organizations and enterprises dealt with the move from GPL 2 to GPL3?

When GPL v3 was being drafted the SFLC enaged me to provide advice on the impact of Australian law on the licence (the SFLC did this for a number of different jurisdictions around the world). One of the aims of the drafting process was to ensure that GPL v3 was as consistent as possible with various legal systems around the world and many projects have adopted GPL v 3. I'm not aware of anyone raising any serious problems with the licence under Australian law.

How is open source software impacting the way vendors monetize software?

Closed source software has the characteristics of what economists call a "natural monopoly". This means that, left to its own devices, it will tend to evolve into a market in which there is one winner and a multitude of losers. Open source and open standards change this dynamic by introducing competition to the mix. The more interesting question therefore is how can we have a dynamic software industry unless we have open source and open standards. Governments around the world are increasingly realizing this.

Do you agree that many organizations and enterprises are hesitant to deploy open source because they don't know how? What can be done to improve this?

I suspect that a major problem for the uptake of open source in an organization is vendor capture. Vendors make their clients' decisions easier by providing them with a lot of product information. Ordinarily this is good, but in some cases vendors can cover decision makers with so much information that there is not enough information about alternatives.

Every organization has someone who is passionate and knowledgeable about open source. Management needs to find that person and start at least listening to them. They should be conducting small open source pilots to familiarize themselves with migration issues. Finally, they should be talking to their peers, because everyone has an open source good news story, whether it's VoIP, CRM, databases or whatever. I actively try to connect my clients with each other if they're willing and have a commonality of interest.

Lower total cost of ownership and lower acquisition costs lead the pack in one survey of enterprise adoption of open source software, while product support concerns and lack of awareness are the biggest hindrances. Does that equate with your experiences?

Waugh Partners' recently released an Australian open source census which indicated there is a lot of support offerings for open source in Australia. I think people are initially attracted by the potential for lower licence fees, but they stay for the flexibility they gain and the "soft costs" they save. From a user's point of view, it means control of your own destiny. For a supplier's point of view flexibility means high agility. They then are unconstrained by the myriad of blockers that the adoption of closed source technologies will put in their way. I have begun documenting some of these blockers on my blog - see my posts on The Invisible Closed Source Overhead.

Who, in your opinion, from enterprise, large organizations or government, is leading the charge in successful and sustainable open source software adoption in Australia?

There is a lot of activity in all areas of the market, although FOSS tends to be more accessible for enterprises which have in-house IT support and enterprises which are larger (because they get better returns to scale). Getting good numbers on these areas is difficult because there is an inherent lag between adoption and announcement. Indeed, in the early years of FOSS adoption organizations deliberately kept their implementations secret because it gave them such a substantial competitive advantage. In fact, just running an open source trial can help secure licensing discounts for existing closed source products.

The position in Government is less clear. I helped the NSW Department of Commerce with their Linux tender a couple of years ago, the NSW RTA with their implementation of an open source desktop, and the NSW Health Department with their open source release of an epidemiology tracking program. All of these were world firsts for a government department. In the ACT, Roslyn Dundas secured legislation which reduced government bias against open source and at the federal level AGIMO published a guide to FOSS procurement. These were also world firsts.

I continue to do government related open source projects but there seems to be less publicity of government open source related successes. Australian governments need a better way to evangelize their open source successes and educate other potential users. They should consider using some of their licence savings to support Australian industry to perform this function.

What do you make of the OOXML debacle, and Microsoft's recent interoperability pledges?

While I helped make OOXML a better document during the ISO process, like many people I remain disappointed by the process at ISO for its adoption. Lingering concern about the OOXML and the OSP remains in the community. This uncertainty inhibits interoperability. Interoperability is of fundamental importance to competition in the software market. The licensing terms of open source ensure a base level of interoperability. Without interoperability effective competition is very hard, if not impossible (although this depends on the product domain). What users signal to their vendors on these issues is very important. To say nothing is to support the status quo. Users who want cheaper software and long term access to their data have to be very clear about the importance of interoperability and open source in their purchasing requirements. Those organizations which are large enough, should consider also covering the API related issues I alluded to earlier. There is already widespread support for OpenOffice and I can only see that growing in the future.

This story, "The low-down on open-source law" was originally published by CIO Australia.

Copyright © 2008 IDG Communications, Inc.

Get the best of CIO ... delivered. Sign up for our FREE email newsletters!