Open Source Software Solutions (Part 3): Educating your Employees about Open Source Software Issues

December 2, 2016

By: Mary Lou Wakimura, Giovanna H. Fessenden, and Mark R. Tredinnick

Hamilton Brook Smith Reynolds

In this series of articles, we have covered the licensing and intellectual property (IP) risks surrounding open source software (OSS) code and the need for software development companies to adopt policies and procedures to manage the use of open source software in a safe and effective manner.  More specifically, we discussed the importance of creating an OSS policy that includes getting to know the OSS code being used in your software products and understanding what triggers the requirements in the associated OSS licenses.  Once you have an OSS policy and the procedures in place to implement that policy, you are ready to educate your employees about open source software issues and why your OSS policy matters.

Software companies need to make careful, educated decisions about the inclusion of open source components in their products.  Properly using the vast and readily available resources of open source communities can be a profitable business strategy.  A well-managed and effective open source utilization policy will allow developers to incorporate OSS code, as long as complying with the licensing obligations is possible and fits the business strategy for the software product being developed.  But employees need to understand the issues surrounding open source software, and why it is so important to follow the established policy and procedures.

Steve Kurlowecz, Senior Intellectual Property Counsel of IBM's (International Business Machines) Analytics business unit, recommends an OSS policy with education at its core,  the goal being  software development companies and their employees understanding why you're counseling about the risks of an open source software license.  According to Mr. Kurlowecz, a fundamental point to convey to employees is "easy access on the Internet does not mean easy to use legally."  When software developers and engineers understand and buy into why maintaining an OSS policy is important, they are more likely to follow the procedures laid out in the policy.

We note that training and education for employees about open source software and the company's policy regarding its use may be the company's most effective tool in gaining control over open source code use.  The goal is not to necessarily discourage developers from use of open source, but to ensure that they have an understanding as to how to handle its use.  Periodic seminars, compliance reminders, and memoranda can help employees appreciate the unique nature of open source software.  With increasingly effective OSS code only a Google search away, it can be very tempting for developers to copy and paste some pertinent OSS code into a company project they are working on.  Education and understanding of the consequences involved with doing so helps fight that temptation.

According to Richard Fontana, Senior Commercial Counsel at Red Hat, Inc., educating on copyright law in the context of OSS code derivatives is a big part of open source compliance.   Having software developers and engineers who are educated on open source issues and copyright law as it pertains to software will not only increase the likelihood of compliance with a company policy, but informed developers can also be a great resource.  As discussed in our previous article, analyzing whether a software product that integrates pieces of open source software triggers the requirements of the attached OSS license (e.g.., whether the software product is a derivative work and/or "distributed") involves challenging technical and legal determinations.  Software developers and engineers are often in the best position to identify and determine how closely coupled are the proprietary and OSS code.

Additionally, knowledgeable developers can design software solutions that use open source software without incorporating the code into proprietary software.  Keeping the OSS code sufficiently separate from the proprietary software can avoid the proprietary software being considered a derivative work.  Most open source software that is modified, distributed, or copied will still have to comply with the attached license's requirements, but as long as that open source software is sufficiently separate from the proprietary software, the restrictions and obligations of the OSS license will not attach to the proprietary software.

Employing software developers and engineers who are educated and interested in open source software can have other benefits.  As Mr. Fontana points out, "there can be tremendous value and benefit in companies starting open source projects or contributing to existing open source projects.  If you are concerned about the risk profile of your developers using open source software, I believe that you really lower your risk profile, which I think is low to begin with, but you lower it significantly by becoming a participant in the communities that you're taking software from.  If you're seen as a peer in those communities, they're going to see you as a friend and not a bad actor if you maybe make a mistake."

In our series of articles, we have discussed the value of (1) knowing the OSS code in your products, (2) understanding the trigger points of the obligations of OSS licenses, and (3) educating your employees about open source software issues.  These three areas are a good starting point for developing an effective open source software policy, but open source software policies are not one-size-fits-all.  Every company should have a tailored policy to manage open source software use effectively in order to avoid intellectual property risks and open source software violations.
 

About

December 2, 2016

By: Mary Lou Wakimura, Giovanna H. Fessenden, and Mark R. Tredinnick

Hamilton Brook Smith Reynolds

In this series of articles, we have covered the licensing and intellectual property (IP) risks surrounding open source software (OSS) code and the need for software development companies to adopt policies and procedures to manage the use of open source software in a safe and effective manner.  More specifically, we discussed the importance of creating an OSS policy that includes getting to know the OSS code being used in your software products and understanding what triggers the requirements in the associated OSS licenses.  Once you have an OSS policy and the procedures in place to implement that policy, you are ready to educate your employees about open source software issues and why your OSS policy matters.

Software companies need to make careful, educated decisions about the inclusion of open source components in their products.  Properly using the vast and readily available resources of open source communities can be a profitable business strategy.  A well-managed and effective open source utilization policy will allow developers to incorporate OSS code, as long as complying with the licensing obligations is possible and fits the business strategy for the software product being developed.  But employees need to understand the issues surrounding open source software, and why it is so important to follow the established policy and procedures.

Steve Kurlowecz, Senior Intellectual Property Counsel of IBM's (International Business Machines) Analytics business unit, recommends an OSS policy with education at its core,  the goal being  software development companies and their employees understanding why you're counseling about the risks of an open source software license.  According to Mr. Kurlowecz, a fundamental point to convey to employees is "easy access on the Internet does not mean easy to use legally."  When software developers and engineers understand and buy into why maintaining an OSS policy is important, they are more likely to follow the procedures laid out in the policy.

We note that training and education for employees about open source software and the company's policy regarding its use may be the company's most effective tool in gaining control over open source code use.  The goal is not to necessarily discourage developers from use of open source, but to ensure that they have an understanding as to how to handle its use.  Periodic seminars, compliance reminders, and memoranda can help employees appreciate the unique nature of open source software.  With increasingly effective OSS code only a Google search away, it can be very tempting for developers to copy and paste some pertinent OSS code into a company project they are working on.  Education and understanding of the consequences involved with doing so helps fight that temptation.

According to Richard Fontana, Senior Commercial Counsel at Red Hat, Inc., educating on copyright law in the context of OSS code derivatives is a big part of open source compliance.   Having software developers and engineers who are educated on open source issues and copyright law as it pertains to software will not only increase the likelihood of compliance with a company policy, but informed developers can also be a great resource.  As discussed in our previous article, analyzing whether a software product that integrates pieces of open source software triggers the requirements of the attached OSS license (e.g.., whether the software product is a derivative work and/or "distributed") involves challenging technical and legal determinations.  Software developers and engineers are often in the best position to identify and determine how closely coupled are the proprietary and OSS code.

Additionally, knowledgeable developers can design software solutions that use open source software without incorporating the code into proprietary software.  Keeping the OSS code sufficiently separate from the proprietary software can avoid the proprietary software being considered a derivative work.  Most open source software that is modified, distributed, or copied will still have to comply with the attached license's requirements, but as long as that open source software is sufficiently separate from the proprietary software, the restrictions and obligations of the OSS license will not attach to the proprietary software.

Employing software developers and engineers who are educated and interested in open source software can have other benefits.  As Mr. Fontana points out, "there can be tremendous value and benefit in companies starting open source projects or contributing to existing open source projects.  If you are concerned about the risk profile of your developers using open source software, I believe that you really lower your risk profile, which I think is low to begin with, but you lower it significantly by becoming a participant in the communities that you're taking software from.  If you're seen as a peer in those communities, they're going to see you as a friend and not a bad actor if you maybe make a mistake."

In our series of articles, we have discussed the value of (1) knowing the OSS code in your products, (2) understanding the trigger points of the obligations of OSS licenses, and (3) educating your employees about open source software issues.  These three areas are a good starting point for developing an effective open source software policy, but open source software policies are not one-size-fits-all.  Every company should have a tailored policy to manage open source software use effectively in order to avoid intellectual property risks and open source software violations.
 

Back to the Top