Developing Programmers .com

Jamie Wodetzki is a technology lawyer. Most of his career has been as a technology / copyright lawyer; and now he works on a software company he started, Exari Systems (previously SpeedLegal). Exari Systems is a Java house which writes their own proprietary document assembly software, uses and contributes to some open source tools, and even hosts an open source Java based XML editor project (Xerlin).

As Jamie happens to be part of the family, I had the opportunity to ask him some questions over breakfast. The meal is significant because Jamie also happens to run a popular Breakfast Blog and said the eggs Benedict at the café were “definitely well above average,” which is impressive given his standards for a good breakfast.

I asked him about two different topics:

• Mixing open source and proprietary software licenses.
• Two particularly scary clauses that seem to be typical in employment contracts.

This article is about mixing and matching open source and proprietary software.

I asked Jamie about two angles on this: Including open source software in proprietary software, and including proprietary software in open source software. The answers were surprisingly similar.

Jamie:

I’ll start with the easy one: including commercial software in open source software. This depends on whether you can get permission from the owner but generally the answer is “no”.

Sarah: What about open source plug-ins, extensions and tools for commercial software? If the open source part doesn’t include the proprietary part but does depend on users already having it?

Jamie:

A separate open source component that requires commercial software is OK, as long as the open source part is clearly kept separate. The only issue then is if a commercial product expressly prohibits open source projects but this is probably rare.

Sarah: Some companies actively encourage open source projects that depend on their proprietary products because it’s a kind of advertising.

Jamie:

That’s right. Just be careful not to even imply you have open sourced the proprietary product.

Sarah: There are four main kinds of open source license that I’m aware of:

• GPL
• LGPL
• BSD
• Creative Commons

and variations on all these.

Are there more major licenses that I’ve missed?

Jamie:

There’s more: The Apache license and its variants are widely used.

It’s a commercial friendly type of open source license compared with GPL. There’s probably more you can find with Google.

Since the interview I’ve Done the search and among other things found a summary of open source licenses.

Jamie:

The bottom line with mixing proprietary and open source software is whether the license is “viral” or not. In general you shouldn’t be able to take something that’s OS and close it. The GPL takes it a step further and says if you use it in something that whole thing must be GPL.

Using GPL software with proprietary software is like using proprietary software with open source: Keep them very separate. Avoid including GPL software in your own, even as linked in libraries. Shared libs may be a gray area here if you’re not shipping them with your product.

The most important point is before you do any embedding of a piece of open source code, establish whether the license is a viral style of license or not. For example, use a library that uses the LGPL instead of one that uses the GPL.

If there’s a clear owner of the open source project then you might be able to get an exception made, by having them personally grant a license specific to your application.

Sarah: Is it worthwhile for companies to open up their source code?

Jamie:

Yes, in the right circumstances. It should be a carefully considered business decision. IBM does it. It can work as a business strategy.

You can harness a bigger development community by opening source. It works will for companies that need robust software but don’t actually make their money from software. For example, IBM sell a lot of hardware.

Sarah: I noticed HP have open source printer drivers, is that the same thing?

Jamie:

The printer companies are really ink companies. They make their money off ink cartridges, not printers or software. So open source licenses should work for them.

Sarah: Is there middle ground between open source and commercial licenses? It seems like most people argue for one extreme or the other.

Jamie:

The middle ground is non-viral open source licenses and dual licenses basically. Then there’s Microsoft’s licensing, that’s semi-open.

There are two issues:

• On what terms can you use and distribute it.
• Do you have the source code?

With Microsoft’s Shared Source initiative, the source is available but you generally still need a license to use or modify it.

Microsoft’s “Shared Source” initiative is actually an umbrella term for a range of licenses for various products that allow various degrees of freedom to view and use source code, depending on the product. Stephen R. Walli has a good article about this.

Sarah: So how does Trolltech’s dual license work? They offer their software under your choice of a couple of different licenses. If you’re writing GPL software you can use their software under the strict GPL. If you’re writing proprietary software then you need to buy a different license for it. As I see it, if you’re making money with their tools then they want a cut.

Jamie:

This is a valid approach and any open source author can take it up if they want to.

One other thing about OS licenses is most of them come with all sorts of disclaimers of liability.

Sarah: So do a lot of commercial licenses.

Jamie:

At least with commercial licenses you know who to go after if something goes wrong.

If you’re going to use an open source product, it’s worth knowing its pedigree. It could be written by some kid as a holiday job, or have parts written by so many people that nobody is responsible for it. So consider, “is there someone I can go after?”. That’s a strength in commercial vendors. If open source software is provided by a vendor be aware of what responsibility the vendor is willing to accept.

Sarah: One common fear is if the open source software is violating a patent.

Jamie:

Yes, patents are an example of this. If an open source product infringes on a patent then any customer using it is at risk. If it was a commercial product then the risk often shifts to the vendor (unless they manage to exclude it).

Sarah: I notice that IBM and Novel and others are trying to mitigate this sort of problem for Linux.

Thanks Jamie!

Jamie works in Australia and that is where this article is most relevant. According to him, American, UK, Canadian, NZ and Singaporean law follows similar principles so this article is relevant in those places too. Please note that this article contains only general principles and that you can not know about law in your specific circumstances without getting personalized legal advice.