A nuts and bolts engineering approach to using open source IP - Embedded.com

A nuts and bolts engineering approach to using open source IP

In the world of product development, time-to-market keeps shrinking and demand for better quality keeps growing. Open Source, which is often thought to be the definitive solution to meet both objectives – faster development cycle and better quality, is on the mind of many OEMs and product companies.

In reality, the companies find it difficult to overcome the FUD (Fear, Uncertainty and Doubt) to make a final decision and say, “Yes, we will use open source in our product.”

In the product development process, at the one end are the engineering people – developers, architects, engineering managers – who are aware of open source and its benefits, but lack the power to take decisions. At the other end, are the management and the legal people, who can take decisions, but may not have sufficient ground-up information. How do we bridge this gap? How can the engineering team convince the management to boldly embrace open source?

In this article I will go over some key factors and guidelines to consider with respect to the use open source in product engineering. The objective is for us, the engineering people, to be prepared with sufficient and solid information to convince our management and legal departments to take that final call with confidence.

1. Select the right open source component
There are a myriad number of open source components available for download and use – how do we know which one is right for us?

Apart from the purely technical factors (choice of programming language, interfaces, memory & load requirement, portability/availability of the component on your specific platform/OS, etc. ) there are a few other factors to consider:

A. Maturity. Questions that need to be answered include: 1) Is the component mature enough to be used in a commercial product? 2) Are there other known products using this component? If it is widely used, the component developers & maintainers like to put up Testimonials and Success Stories on the website with links. (We can use these as pointers, but need to do own validations! )

A look at the older releases, release timeline, change log, established processes (daily builds, a documented patch submission process, etc.) and support mechanisms are good indicators of the component history and maturity.

B. Licensing. Two important considerations here are 1) Is the component license clearly documented – typically on the component website; and 2) How closely do you need to analyze the license (We will look at how to do this in detail later in this article ).

<>C. Support. . Three things to look for here are 1) Availability of documentation (which could be in the form of wikis, doxygen generated documentation ), which will make the developer's/integrator's job easier; 2) Unofficial documentation.

Even if official documentation is not available, there could be several unofficial ones put up by other enthusiastic users. A Web Search should reveal these hidden gems; and 3) Active community, forums and mailing lists, all highly desirable not only for integration support, but also to fix any detected bugs.

2. Analyze the License
Once we decide on a particular component to use, the next step is to analyze its license, to see if it fits into our scheme of things. Often, the component website mentions the license that applies to the component.

In addition, it is strongly advisable, to actually download a latest version of the component and check the embedded LICENSE/README file. Sometimes, there can be differences between the two and it is best to get this clarified from the developers/maintainers of the component.

The complete license terms and conditions are usually in legalese. From an engineering point of view we just need to know:

1) Name or type of the license
2) Can I use it with other components (open source or closed source), in the way I want to (build together, link, service or utility)?
3 Should we declare anywhere that we are using such and such open source software?
4 What are the source re-distribution rules?

For engineering purposes, some common open source licenses, their implications and impact on other open or proprietary components when used in a larger product are illustrated in the matrix in Table 1 (downloadable as a PDF file ) .

Important note: This table is not a legal description. This is a simplified summary of important terms and conditions for first-level assessment by engineering team. It is considered here that the open source component is used as-is without modifications – an assumption which is true for most products. If the component is modified, there are more factors to be considered. Also, the version of the licenses analyzed here are the ones in vogue currently.

3. Create a community of experts It may become a little tough to assess a component's capabilities and license implications correctly at an individual level – that is when a community helps. Several like-minded engineers and architects can come together to form an informal community within the organization.

This community can collectively assess quality, analyze licenses, address queries and resolve concerns. A community also has a better leverage in convincing the decision makers than individuals. A few other things a community can do include:

1) Become go-to guys for anything related to open source
2) Create a platform to debate about open source, spread open source awareness and encourage fellow engineers to look at using open source effectively
3) Create FAQs on common licensing queries
4) Facilitate creation of ready-to-use packages of common open source components for use within the organization

Over time, the community of experts has good chance to be recognized as a governing and decision-making body in the organization.

4. Work with management and Legal to formalize the use
Now, to the final step – convincing the management to accept our choice. We use all the data, facts and figures that we have collected so far to make a strong case. For each open source component, it is necessary to put together the following:

1) Applicable license
2) Impact/implications
3) Known uses in other products
4) Recommendations of the 'expert community'
5) Link to the actual version of the component downloaded and used

If there are any gaps, missing information or unclear terms, let us highlight them. While we are at it, putting all the information in an easy-to-assimilate presentation format or organized spreadsheet format does not hurt!

Legal has more work to do from here – due diligence, checking if the open source component is really what it claims to be, checking if there are any “contamination”, checking copyright ownerships and possible business conflicts with copyright owners, and any legal paperwork, if the product development is distributed/outsourced.

There are many products in the market which use open source. Linux-based wireless routers are good examples of commercially viable open source products. Lack of awareness, a certain fear of the unknown and “it's not worth the risk” attitude have been keeping the product companies away from open source. Techies unite! There is much we can do to bring-in open source gently and firmly into the conventional product development process.

(Please note that we are not talking about using open source without the knowledge of the management here! Such a thing is not done and could land everyone in trouble. )

Open source not only fits into product development schema, but also makes the whole process better and faster. And, yes, it can also make some good money.

Girish Managoli is Senior Technical Manager at MindTree Research – MindTree Limited. He holds a Bachelor's degree in Engineering from University of Mysore, India and has more than 12 years experience in the IT industry. As part of the Bluetooth team at MindTree, Girish works on development of products for the company's customers, many of which use GNU/Linux and other open source software. As a founder-member of Linux Community and member of Open Source CoE at MindTree, Girish addresses licensing issues and encourages use of open source. He has also contributed to and created open source projects. Girish can be contacted at Girish_Managoli at mindtree dot com.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.