Don't be an Open Source Ostrich

Lots of companies are currently analyzing the impact of a decision to move from closed source to open source (like Intalio just did). And it is critical to consider the legal implications of these decisions, especially when it comes to the type of license to use, what software your company already leverages, etc. You want to avoid the “whoopsy” moments that happen when you discover that you have been shipping some modified GPL code without contributing back, etc.

I found this essay from lawyer Dennis Kennedy coming very handy in that context. Do take a look, it is clear and well written, and provides useful background. Here is a summary of his checklist:

1. Understand the Different Approaches That the Open Source Licenses Take.
2. Pay Special Attention to the General Public License.
3. Remember the Source Code.
4. Make Reasonable Comparison with Commercial Software.
5. Think in Terms of Choosing, Rather Than Negotiating, Open Source Licenses.
6. Do Not Confuse Open Source with Public Domain.
7. Inventory and Assess What You May Already Be Using.
8. Open Source Use Requires Open Source Training.
9. Reasonable Policies and Procedures Are Not Optional.
10. Treat Open Source Policy as a Team Game.

My favorite quote: “Don't be an Open Source ostrich”, which refers to the sort of default reaction of executives when you bring up the notion of open sourcing portions of the stack a company has spent years and hard cash to develop. As Dennis puts it in his conclusion:

Open Source software is not likely to go away nor are you likely to avoid it. As always, “be prepared” is the best motto. Addressing this area from a reasonable knowledge base, with your eyes wide open, only makes good sense in today's business environment. These ten tips will help you get your Open Source house in order and pave the way for effective and wise use of Open Source software with your legal risks kept within your level of comfort.

Thanks to Alex Muse for the pointer.

Comments

[Kevin Burton]

Here's the only thing you have to remember if you're a company dealing with OSS

If you don't want to have to release your code you can essentially use any OSS license. You can use the GPL but only in a server product which you never ship as source (without having to give the code away).

Don't use the GPL in client-side code without giving it away. You'll get nailed in the press and make geeks/bloggers angry.

If you've modified code that isn't core to your business throw it over the fence. It's better to give it away than it is to maintain it (which will end up costing you a lot of money).

My $0.02...

Kevin

[Solveig Haugland]

Hi,
This is an excellent post--open source is just a wee bit different, and with the emphasis on "free" the licensing details can be forgotten.

Another item that can get lost in the rush, as noted in #8 on the list, is just plain old training and documentation. There might just be a wiki or a text file available for the product you're switching to, but there might be far more out there. Google around, try Amazon, and make sure that users have what they need, ahead of time. When I do training, I'm almost always called in after the switch, when students can be confused and resentful. Giving training ahead of time means they'll be better prepared when they absolutely have to get the quarterly reports out, or just do their everyday jobs.

And of course there's the human factor, mentioned in #10. People love their tools. They will complain about switching. A little heads-up ahead of time and training, even if it's as little as a couple inhouse lunch-and-learns, and meetings that take into account user concerns, helps take the edge off the change.

~ Solveig