There is a classic scene in the movie “Casablanca” where Claude Raines attempts to close down Rick’s Cafe. When Humphrey Bogart demands to know why, Raines says, “I’m shocked! Shocked to think that gambling is going on in this establishment!” Meanwhile, the casino employee walks up and hands him his winnings.
I’m reminded of that scene every time I hear about responsible companies turning a blind eye to the internal use of open-source software by their employees. Maybe they think it doesn’t concern them. Maybe they are confident a policy is already in place to control any future use of open source. They might not even realize that their independent-minded developers are already using it.
Several weeks ago, we discussed the need for businesses to do some internal soul searching to develop an open-source policy that is consistent with the company’s corporate philosophy. It is not an easy process, which is why some CEO’s might find it simpler to keep their heads buried in the sand. Even after going through this process, it is still possible for companies to overlook some important due diligence. If the cart is before the horse, the result might be that the policy is broken before it can even be put to use.
When was the last time you checked with your developers regarding their attitude toward open-source software? Do you know whether they have the right licenses to protect themselves and your company? How can you formulate a realistic corporate policy if you don’t even know what questions to ask? Asking the right series of questions can make a huge difference in whether or not you get an accurate picture. Here are some basic questions to ensure the feedback you get is useful.
What open source software are you currently using?
Find out what your developers and employees are currently using, and be especially sure to review all the applicable licenses. Do not assume that all open source is governed by the terms of the GPL. There are other licenses, and your rights and obligations can vary greatly depending upon the applicable license.
It also seems likely that software developers do not always accurately identify the applicable license for the open-source software they use. So a good corporate open-source policy should be tailored toward as many specific licenses as are practical.
What open-source software do you plan on using in the future?
More importantly, do you know what license terms would govern the use of that open-source software? If you know what your development team is strongly considering, you can tailor your initial open-source policy to the applicable license terms. If you do this type of homework at the outset, it can save you from potential headaches in the future.
How does the development team plan on using the open-source software?
This answer will surely change over time. But, again, it is important to know in advance what the development team plans. Is the open-source software going to be used strictly as a development tool? Does the team plan on modifying and incorporating open-source software into their final product on the opposite end?
Suppose you find out that your development team has no plans to modify or distribute open source. In that case, the first version of your corporate policy might allow you to sidestep some of the thornier issues involving handling contributions and modifications.
Developers are generally independent-minded people. Just because they insist they have no plans to make modifications or distributions does not mean they won’t change their minds. That’s okay as long as they let you know. Then you can update the policy as required.
What kinds of third-party software — non-open-source software — are you currently licensing for inclusion with your software or hardware products?
Keep in mind that an open-source policy needs to take into account a review of any and all third-party software licensed for inclusion with your hardware or software products — even if that third-party software is not open source. Make sure your attorney takes a look at these inbound license agreements.
Licensors of inbound technology do not always advertise the fact that their software contains open-source components. Have your attorney ask your third-party software licensors to what extent they use open-source software, and design your corporate open-source policy to address any applicable issues. Be prepared, before this becomes a major problem.
Ideally, no one would ever license inbound technology without having a license agreement that requires the licensor to reveal all uses of open-source software within their technology, and any open-source license terms that might affect the future use of that software. In reality, this is not always the case. You might already have a license for the inbound technology but the agreement is silent on the open-source issue.
Or the vendor might insist that its software does not contain any open-source components. Whether that is true or not, make sure you know your legal responsibilities under any applicable open-source licenses.
Reviewing the inbound software licenses can reveal any constraints against combining or including the inbound software with open-source software. While the odds of older inbound technology licenses covering this topic are low, both Microsoft and Oracle use licenses that prevent the redistribution of some of their code with open-source software. This is intended to minimize the risk of the “viral” nature of the GPL license.
Smart policies are not written by attorneys in a vacuum. They need input from developers and business teams who have done their due diligence. Be smart. Do your homework ahead of time, well before drafting your open-source corporate policy. If you do, the chances are good you won’t be “shocked” to learn that your policy may not be relevant at all.
Phil Albert, a LinuxInsider columnist, is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.
Loading ...
Sorry, but isn’t management supposed to keep track of things like licencing. If they don’t get a new management.
It really doesn’t matter if its open source or not. Most open source licences including the GPL allow in house work without releasing any code to the public. Most propriatory licences don’t so perhaps it would have been better to say a word of warning about that.
This article was probably payd for by Microsoft to point out open source licences as something dangerous, when they in fact not are more dangerous than any other licence.
Whats dangerous to a company is to have bad management.