Open source regulations have unusual requirements for success. Learn how open source lawyers can help their employers find a viable path forward.
As I shared in part one of this two-part series , I am an open source attorney at Red Hat. An important part of my job is providing information to other companies, including their in-house counsel, about how Red Hat is adopting a fully open source development model to build enterprise-grade products, and answering their general questions about open source licensing. After hearing about Red Hat's successes, the conversation these lawyers have with me often turns to how their organizations can evolve into more open source aware and capable organizations, and they often ask me how they can improve their practices to become more proficient. Provides open source legal advice to employees of its organizations. In these two articles, I will share what I typically tell in-house counsel on these topics.
Always find a feasible path
What makes my employer, Red Hat, unique in its use of open source software is that our development model starts with an open source community with thousands of contributors and results in a final product that is tried, tested, and trusted. More specifically, through our unique development model, we start with community-created open source software and work on each project to strengthen security, fix bugs, patch vulnerabilities, and add new features. We then contribute these improvements back to each project so that they benefit the entire open source community. The benefits of this approach are important and include:
- Leverage external innovation through collaboration between internal teams and others outside the organization;
- When an existing or potential community is working on the same problem as you and can collaborate, you avoid the costs and inefficiencies of developing and maintaining an open source solution yourself;
- Through productive collaboration with partners and the upstream project community, the costly maintenance of downstream branches of the main project can be avoided.
- Some companies find it tempting to create non-public branches of upstream code because it is a quick way to solve a specific use case, or because they are unwilling to collaborate in the community. However, the long-term maintenance burden of such a branch may be prohibitive due to increased development costs, loss of interoperability, and other reasons. In contrast, centralizing development in the original upstream community spreads development costs among all participants.
With a few exceptions (such as Red Hat), most organizations using open source software likely have a proprietary software licensing model (or the SaaS equivalent) and license proprietary software as part of their business. These organizations believe they have software components that provide some competitive advantage and do not want to see these components made available to others under open source terms. This is understandable. However, I would encourage any open source lawyer consulted on such matters to urge their clients to adopt an open source development model, especially for all software that is undifferentiated and common.
For example, if your company develops an application for mobile phones and you need a software module to read and write PNG image files, it will be much cheaper to use one of the popular open source PNG software modules on GitHub. Encoding and decoding PNG images may be indistinguishable to your business, so why spend valuable engineering time writing your own version? Additionally, writing your own module for this functionality may also cause compatibility issues with other software that uses commonly available open source modules. Why is this? Although your modules and open source modules may have been written to encode and decode the published PNG specification, sometimes the specification may be interpreted differently and implementation errors may occur. Everyone using the same module to perform this functionality ensures compatibility for the majority of users and reduces development and maintenance costs.
It's also important to realize that you may need some software to remain proprietary and not subject to open source terms. Depending on your system's software architecture and the open source license used, software code that is intended to remain proprietary may become subject to the terms of the open source license unless certain measures (beyond the scope of this article) are taken. This is where it would be useful to provide some consulting services to clients regarding license selection and architecture.
Find flexible solutions
Organizations that previously primarily licensed proprietary software are gradually increasing their use of open source software, but the requirements for review and approval are likely to grow (even exponentially, in my experience). Such organizations may struggle due to resource constraints. Here are some flexible solutions you can adopt.
Authorize and delegate to others
Lawyers cannot and should not be gatekeepers. That's inefficient and will definitely lead to bottlenecks in development and release times, creating frustration and lost revenue. Instead, approval authority should be given to competent individuals in product or project management and engineering. This allows organizations to effectively remain flexible. Educating your customers (see next section) is critical to successfully achieving this.
One approach I take is to provide open source training to the entire engineering organization so that they can make basic licensing model and architecture choices, while providing more specialized training to software developers to enable them to provide more complex guidance and decisions . Also consider clear limits on permissions at each level, including what types of issues and decisions must be escalated to you as their open source attorney. Your organization's specific authorization level will depend on your team's experience with open source and sensitivity to certain open source issues.
Educate customers
I've found training to be one of the most effective tools for migrating your organization to a more open source-minded organization. Training your software engineers and product managers is critical. Let me elaborate.
Although your software engineers are on the cutting edge and may generally be very knowledgeable about open source issues and software licensing, it's still important to train them based on your organization's specific requirements. For example, your company may only allow the use of permissive open source licenses, and may have certain requirements for its copyright notice and source code availability. To avoid problems in development that must subsequently be corrected (a costly and time-consuming practice), it is best to train engineers to minimize the possibility of inappropriate behavior, especially at the beginning of any development process (see next section ).
Product managers must also receive training. In many companies, product managers are responsible for the classic four aspects of marketing (product, price, positioning, and promotion) and are responsible for the entire life cycle of a product from cradle to grave. Every aspect of a product manager’s job can be affected by the use of open source software. For the same reasons mentioned above, it is useful for them to understand the requirements for using open source software. Additionally, and more importantly, product managers’ significant influence within an organization means that they are often able to make necessary changes to processes and policies. Product managers can be one of your strongest advocates for process changes for Openness.
Early detection
Solving open source licensing issues near the end of the development process is difficult and costly. As the software's release date approaches, the architecture and open source software modules are chosen and difficult to change. If an issue is detected, such as "copyleft" software embedded in a proprietary software module (when that proprietary module is not intended to be subject to open source terms), modifying the architecture or module at this stage of development can be difficult and costly expensive. Instead, the process of architectural analysis and open source module selection should occur early in the development process so that less expensive and more effective corrections can be made.
The “rewards” of open source regulations
Practicing open source regulation is a rewarding career because the ability to influence an organization in an "open" direction has great benefits. Success depends on your ability to find solutions that are feasible and flexible as your organization grows and matures.
About the author: Jeffrey R. Kaufman is a senior business legal advisor in the open source legal team of Red Hat, the world's leading provider of open source software solutions. He also serves as an adjunct law professor at the University of North Carolina. Prior to joining Red Hat, Jeffrey served as patent and open source counsel for Qualcomm.
Translator profile: Xue Liang, director of the Internet Business Department of Jihuizhijia Intellectual Property Consulting Company, is good at patent analysis, patent layout, competitor tracking, FTO analysis, and open source software intellectual property risk analysis. He is committed to providing Internet companies and high-tech companies with Intellectual property consulting services.
