A “cheat sheet” for entrepreneurs, lawyers, and engineers.
Do we need an open source policy?
You have a policy, whether it is written down or not. It could range from “no open source at all” to “anything goes.” The question is: does anyone follow it? Is it sensible for your business? Written policies are useful to communicate your expectations about use of open source in your organization, particularly to outsourced developers or engineers in subsidiaries and affiliates, whom you may not see every day.
My company doesn’t use open source. Why should I care about it?
You are wrong. Your company uses open source. You just don’t know it yet. See question #1 about your policy.
Should my engineers contribute to open source projects on their own time?
It’s likely they are already doing so, but they may need help understanding whether they are encumbering your intellectual property rights or complying with your expectations. Some companies don’t allow their engineers to contribute, but there can be a downside to that. The top engineers will want to contribute, and by contributing, you may be able to set the direction of open source projects so they will meet your needs.
I heard the GPL isn’t enforceable. Is it OK to violate it?
That’s wrong, and no.
I read the GPL and don’t understand it. Help!
That’s OK, most people don’t. You can’t understand it very well by reading it on its face. (Otherwise there would not be many long FAQs about it on the FSF web site.) Most questions about the meaning of GPL have straightfoward answers, but if you are asking, for instance, what is a “derviative work,” or waht is “distribution,” you probably need expert help.
Using open source seems complicated? Is it worth it?
Usually it is, but there is no one answer. Open source licensing works better for some software than other software. The market seems to think it worthwhile — most companies use it.