Open source software has the following mandatory properties. Using open source software to create successful commercial products

Open source software has its admirers, and lately when it comes to the development of some kind of "national" products, so basically open-source is meant. Paradoxically, the interest in this type of software has generated a lot of distortions and misconceptions that in practice prevent its distribution.

Our company has been participating in open source projects since 2005 - and thanks to the development of our own open source solutions (OpenVZ, CRIU projects), participating in other open source projects (QEMU, OpenStack, libvirt, libcontainer, etc.). Over the past 10 years, we have collected some of the most common myths about open source software. I will go over each of the misconceptions and explain why it is wrong. Surely, you will remember as many more, but, in my opinion, these five are the most "hellish".

The open source project is an open source project.

Any software project consists of many artifacts: project source code, information about uncorrected defects, test source code, documentation. The source code of the project is only a part of it, free access to which does not give the right to call the entire project open. In addition to the source code, other development artifacts should be freely available, and the more artifacts are open, the more the project is open to contributors (people who want to contribute to the project). In addition, transparent processes are needed between all community members, open communications in the project, etc. All these measures will only contribute to the development of the project and fruitful cooperation of the community members.

The quality of open source software is worse because anyone can write code for it.

The main principle of open source software - open joint development - in itself is a guarantee that low-quality code, crutches and patches simply cannot be hidden from other participants. A person, participating in such projects, is ready for the fact that his work will be subjected to both analysis and criticism, and, therefore, will not cheat. His reputation is at stake, and no one wants to lose it.

In addition, in some communities (for example, the community around the development of the Linux kernel) there is a strict principle - only the best, tested and ideal code is accepted into the original kernel. An attempt to add low-quality changes will be rejected, the second attempt is fraught with loss of reputation for the person or company contributing.

That is, an open source project really makes it possible for any person to take part in writing code, but in serious projects, due to the high entry threshold, the code will not be accepted from people with insufficient level of expertise.
Most large IT companies (IBM, Google, Canonical, Parallels, etc.) have entire departments where specialists are paid to work on open source projects and thus work indirectly on the company's products.

Separately, it is worth mentioning that companies that develop products based on open source projects, during testing, are interested in improving the code of open source projects that they use. Therefore, all discovered problems must be fixed and ensured that this fix was added to the main branch of the project in order to have as few differences as possible in your code and the code of the open project. Our products use the code of other open source projects, so we fix the problems found in the code of these projects and send them to the upstream. This was the case with vulnerabilities in the RHEL kernel: Red Hat noted Vladimir Davydov for discovering serious vulnerabilities CVE-2014-0203 and CVE-2014-4483 in one of the updates to the RHEL6 kernel (the second problem, by the way, was found using one of our automated tests, using the Linux Test Project). Vasily Averin received gratitude for finding error CVE-2014-5045, Dmitry Monakhov for CVE-2012-4508. The fact of good testing of the Linux kernel was even noted by Andrew Morton (who is this?): “I'm interested. Over the past few months, the folks at @ openvz.org have found (and fixed) a bunch of obscure but serious and fairly ancient bugs. How did you find these bugs? "

Outcome

In fact, all of these myths arise for the most part among users who are either just starting to work with OpenSource software, or have not tried it at all. The best way to get rid of prejudice is to start working closely with such solutions.
We recently updated our product Virtuozzo 7. If you are also interested in creating the best container virtualization technology, then

The efforts of computer equipment manufacturers to promote solutions backed up by strong marketing support are widely recognized open-source software(open source software). In modern official use in Russian, this phenomenon is usually called free software(SPO).

The essence of the concept consists in several principles for the creation and distribution of open source software:

• availability of source codes for everyone;
• distribution licensing policy based on one of the community-approved licenses (see opensource.org);
• the ability to directly participate in the development and correction of software errors on their own;
• the ability to change some software functions and adapt to new conditions (subject to the availability of changes to the entire community);
• maximum compatibility with open standards;
• the ability to work in various operating systems and on several platforms (cross-platform).

These principles are used to create the majority

SPO. It is worth noting that there is a noticeable difference between free and free ON. Despite the fact that most open source software licenses are free distribution, this property alone is not enough for the software to be considered free software.

Open source has already won a number of important victories over some of the strongest proprietary software vendors. Specifically the web server Apache is far ahead of similar products from other companies (including Microsoft) in terms of market share due to its low cost, vendor independence, many experienced users in its administration, and developer support. Linux bypassed all other types in terms of supply Unix for platform Intel, including the long-held leadership SCO. Open source DBMSs have a strong presence in the open source OS and popular low-end Internet marketplaces. The threat to proprietary software comes from the benefits of open source software similar to those of the Internet, i.e. openness, freedom of adaptation, etc.

Free software already has a strong presence in server operating systems, Internet infrastructure, web application servers, small business and departmental DBMSs based on web databases with dynamic web page generation, technical and embedded computing systems, and software. for server devices. Speaking about the infrastructure of the Internet, it should be noted that most devices run operating systems and other open source software. These devices include domain name servers, routers, switches, firewalls, gateways, load balancers, application and database servers, and more.

Given these advances, open source software jeopardizes firms whose main source of income is client access fees and proprietary software licensing fees. Open source brings the legacy and consumer commodity business model in the hardware marketplace to software — a model that is difficult for a traditional software vendor, especially a leader, to adapt to.

Many of the vendors using open source business models did not develop as vendors of traditional software from the outset. As their share of the open source software market grows and its position in strategic Internet markets is growing, traditional software vendors are identifying threats from open source and the opportunities presented by new business models. Naturally, legacy software vendors have the ability to adopt these business models in whole or in part, depending on their product portfolio. Even so, open source poses a tangible and very real threat to the usual business patterns of software companies.

There are four main open source threats to closed companies.

• Price pressure. Since open source licenses, in fact, require free distribution of software and its modifications, prices for similar traditional products must be reduced in order not to yield to open source software and to fight the loss of market share. For instance, SCO cannot take $ 2,000 for Unix for platform Intel, while Linux available for free, a Microsoft monopolizes the desktop sector. Traditional vendors can, however, partially recoup their losses by making their software products of higher quality than JV O and charging additional fees for this.
• Good enough functionality.“Good enough” software (but not the best) can partially crowd out the products of traditional software vendors, who too often target the mass market. More complex (and expensive) functionality in the early stages of its development is always targeted at a relatively small group of professional users. But even manufacturers operating in this market still need to clearly understand that the market for highly developed software will expand and deepen. If the advanced functionality fails to appeal to a wider user base, customers will naturally buy open source alternatives, albeit less advanced ones. In very large mass markets, dominant open source software vendors, in addition to increasing their supply, have ample room for growth through complementary product and service strategies. The size of the mass market in itself ensures lower prices due to high volumes of deliveries, which allows end users to receive tangible profits even with a slight increase in the cost of their products.

In some cases, open source software can even bypass traditional products in functionality. For instance, Apache became the first web server to offer a popular Internet function among providers IP-aliasing, allowing to host several Internet domain names on one system.

• "Network Effects", due to knowledge and study of software and tools for mass use. The cost of training users of the new technology represents a significant portion of the total cost of ownership, more than the price of the software product itself. A company with a large user base familiar with the product and its accompanying tools can leverage this familiarity by releasing new versions or entering related markets. This kind of network effect can vary depending on the type of user - software developers use API, system administrators - specific administration tools, users work with graphical user interfaces, and managers establish relationships with suppliers. Once formed, this network of partners and users of open source solutions is no longer destroyed and allows you to solve marketing problems of a smaller order, such as gaining adherents and customer loyalty.
• The pressure of standardization. The latest threat from the open source movement is its tools and culture, which sees its enemy as its enemy all manner of technological barriers erected by traditional software vendors.

Recently, the most rapidly developing direction in software is the so-called "commercialopen-source ", those. JV O supported by conventional commercial companies. The corporation should be considered one of the leaders in this area. Sun, which is developing several large projects in this sector: OpenSolaris OS, DBMS MySQL, office suite OpenOffice.org and virtualization environment Virtual Box. As a rule, there are several versions of such software, including a commercial one. When paying for a license, the user receives technical support, as well as, in some cases, special tools for convenient work that are not available under an open license. That is, with small needs, companies can use free or free versions of software, and with an increase in requests, they can buy commercial extensions without changing anything in their infrastructure and applications. Thus, the commercial version of open source software directly competes with the development of traditional companies, for example Microsoft, which is actively creating special licensing schemes for use in the Internet environment (we are talking about server software).

As a result, open source software on the Internet plays a system-forming role, supporting and developing the basic principles of building the Web. In addition, the use of open source software is relevant from the point of view of focusing on providing services instead of selling goods. Therefore, when creating Internet systems, it is worth focusing on open standards and software that implements them, since only this way will provide an opportunity for business development and new opportunities for electronic markets.

The use of open source software to support Internet technologies is natural and necessary from the point of view of the properties of scaling, globality and compatibility. For example, increasing the number of servers or other infrastructure devices does not require additional investment in software, which provides more flexibility than proprietary software. This becomes especially true when the cost of the software exceeds the hardware component of the project. The requirements of globality and interoperability are implemented thanks to good support for cross-platform open source software and the use of open standards, which allows maintaining a high level of interoperability even with many competing products and platforms on the market.

In the light of modern development of service applications based on web technologies, open source software in combination with inexpensive computers (nettops and netbooks) can significantly squeeze traditional desktop and mobile systems, which are based on the operating system. Windows and traditional office suites. Using lightweight specialized OS with a kernel-based GUI Linux and modern web browsers allows you to perform most everyday tasks on net platforms using only open source software.

Open source software has its admirers, and lately when it comes to the development of some kind of "national" products, so basically open-source is meant. Paradoxically, the interest in this type of software has generated a lot of distortions and misconceptions that in practice prevent its distribution.

Our company has been participating in open source projects since 2005 - and thanks to the development of our own open source solutions (OpenVZ, CRIU projects), participating in other open source projects (QEMU, OpenStack, libvirt, libcontainer, etc.). Over the past 10 years, we have collected some of the most common myths about open source software. I will go over each of the misconceptions and explain why it is wrong. Surely, you will remember as many more, but, in my opinion, these five are the most "hellish".

The open source project is an open source project.

Any software project consists of many artifacts: project source code, information about uncorrected defects, test source code, documentation. The source code of the project is only a part of it, free access to which does not give the right to call the entire project open. In addition to the source code, other development artifacts should be freely available, and the more artifacts are open, the more the project is open to contributors (people who want to contribute to the project). In addition, transparent processes are needed between all community members, open communications in the project, etc. All these measures will only contribute to the development of the project and fruitful cooperation of the community members.

The quality of open source software is worse because anyone can write code for it.

The main principle of open source software - open joint development - in itself is a guarantee that low-quality code, crutches and patches simply cannot be hidden from other participants. A person, participating in such projects, is ready for the fact that his work will be subjected to both analysis and criticism, and, therefore, will not cheat. His reputation is at stake, and no one wants to lose it.

In addition, in some communities (for example, the community around the development of the Linux kernel) there is a strict principle - only the best, tested and ideal code is accepted into the original kernel. An attempt to add low-quality changes will be rejected, the second attempt is fraught with loss of reputation for the person or company contributing.

That is, an open source project really makes it possible for any person to take part in writing code, but in serious projects, due to the high entry threshold, the code will not be accepted from people with insufficient level of expertise.
Most large IT companies (IBM, Google, Canonical, Parallels, etc.) have entire departments where specialists are paid to work on open source projects and thus work indirectly on the company's products.

Separately, it is worth mentioning that companies that develop products based on open source projects, during testing, are interested in improving the code of open source projects that they use. Therefore, all discovered problems must be fixed and ensured that this fix was added to the main branch of the project in order to have as few differences as possible in your code and the code of the open project. Our products use the code of other open source projects, so we fix the problems found in the code of these projects and send them to the upstream. This was the case with vulnerabilities in the RHEL kernel: Red Hat noted Vladimir Davydov for discovering serious vulnerabilities CVE-2014-0203 and CVE-2014-4483 in one of the updates to the RHEL6 kernel (the second problem, by the way, was found using one of our automated tests, using the Linux Test Project). Vasily Averin received gratitude for finding error CVE-2014-5045, Dmitry Monakhov for CVE-2012-4508. The fact of good testing of the Linux kernel was even noted by Andrew Morton (who is this?): “I'm interested. Over the past few months, the folks at @ openvz.org have found (and fixed) a bunch of obscure but serious and fairly ancient bugs. How did you find these bugs? "

Outcome

In fact, all of these myths arise for the most part among users who are either just starting to work with OpenSource software, or have not tried it at all. The best way to get rid of prejudice is to start working closely with such solutions.
We recently announced an open development process for the next version of our Virtuozzo 7 product. If you are also interested in creating the best container virtualization technology, then

annotation

This article focuses on the benefits, strategic considerations, obstacles, and opportunities associated with using open source software in commercial products. Using the Eclipse-based Integrated Development Environment (IDE) as an example, we will discuss the differences between protective and nonprotective software source code licenses. When integrating or linking open source with "proprietary" closed source, proper care and caution are often required. Various legal issues should also be borne in mind, such as the potential for patent infringement. We will also try to explain why the basic principles of using open source software in the information technology (IT) environment do not apply to commercial products for embedded devices.

The QNX Momentics IDE as a Case Study for Using Open Source Software

Back in 2001, when many software firms were struggling to cope with the general collapse of the IT stock market, especially those related to e-business on the Internet, QNX Software Systems made the strategic decision to start developing a new integrated development environment (IDE) for the market. embedded systems. The company already had a solid track record of developing a series of tools used in the development of embedded devices, but the company realized that creating an IDE would help to stay on top of the wave in a highly competitive environment. The decision to create an IDE was also driven by a shift in focus in customer requirements. During the downturn, budget-constrained customers became more interested in solutions that could maximize productivity and make them more mobile (flexible) in their work, which would improve overall economic efficiency.

For QNX, developing an IDE was "a bet for the future" because at the time the cost and effort of developing a project was out of the reach of most embedded system tool vendors. Fortunately, QNX has worked closely with IBM across various segments of the embedded device market. Through close collaboration, IBM has shared its plans with QNX to release an open source IDE that has become the foundation for the Eclipse platform.

IBM offered to leverage QNX expertise to adapt IDE technology to the needs of developers building C / C ++ embedded applications. Almost immediately, QNX pointed out the compelling benefits of using an open source IDE. For example, for such an environment it would be possible:

• eliminate dependence on a single vendor, which is usually associated with the need to license the window platform;
• offer the source code for customization to the needs of the customer;
• engage major industry players to support and build an ecosystem of complementary technologies and plug-ins;
• provide customers with a stable architecture that can support product differentiation;
• to enable embedded device developers to use standard workstations as a development platform suitable for working with information technology applications (in the widest range of applications).

Finally, the separate possibility was considered that the IDE could gain popularity and become the de facto standard, which would allow QNX to use the platform to capture the marketplace of large ecosystems of third-party developers and tools.

Founding the open source project Eclipse.org

The Eclipse Consortium was founded by Borland, IBM, Merant, QNX Software Systems, Red Hat, and SUSE in November 2001. In early 2004, the Board of Stewards reorganized the Eclipse Consortium into a non-profit corporation called the Eclipse Foundation.

From the beginning, Eclipse has been a truly open source project. The project offered both free open source technologies and access to a community of the most educated and advanced developers in their field. Thus, this technology turned out to be a universal platform for integrating all types of development tools. It is based on an open, extensible architecture and is clearly licensed as a royalty-free free redistributable product. Community contributions to the Eclipse project are based on the Open Source Software (OSS) standard development model, but most members also offer commercial development based on the Eclipse platform.

Tool repository creation project

In December 2001, QNX began building its QNX® Neutrino® RTOS, based on the Eclipse IDE. In the company's view, the IDE should have great functionality, focus on working with C / C ++ languages, have deeply integrated tools for debugging, profiling, analysis, and building embedded applications. From the outset, the QNX team intended it to be a multipurpose and multilingual IDE that supports multiple tooling platforms. This included:

• several tool platforms: Windows, Solaris, QNX Neutrino RTOS (self-hosted development);
• several target architectures: ARM, MIPS, PowerPC, SH-4, x86;
• programming languages ​​C, C ++, Java.

Since then, the IDE has continued to grow to include support for the Linux platform and support for additional processor architectures, including XScale processors.

The project was launched in the "extreme programming" style. A team of 12 best engineers was selected in the company. They were given a special room, isolated from all distractions, and placed at their complete disposal.

The group was given the necessary authority in the field of decision-making, a tough work schedule was drawn up for them, on the verge of risk, with the release of the beta version of the product in 16 weeks, and the commercial version by July 4, 2002. The group met all the set deadlines and released a new product - dubbed the QNX Momentics® IDE - exactly on schedule, a testament to the potential in open source software to reduce time-to-market.

From idea to product delivery - less than 7 months

Building on the Eclipse platform, the QNX team completed a very powerful and versatile IDE for embedded software development in six months. The IDE supported cross-platform development across multiple tool platforms and multiple programming languages, and supported the most popular embedded target processor boards. With the Eclipse platform, QNX was able to:

• use GNU compilers and command line tools for cross-development;
• support third-party plug-ins such as IBM WebSphere for embedded Java and Rational ClearCase for model-driven development;
• create additional tools for building systems, managing target devices, analyzing memory, profiling systems and applications, etc.

In fig. Figure 1 provides an example of how the Eclipse platform reduces the cost of creating an IDE, allowing companies to focus on the upper tiers of development, where real innovation is actually created. For example, using the Eclipse platform, QNX was able to easily create several innovative visualization tools that allow you to penetrate deeply into the embedded system and display its behavior.

Contributing back to the community

The strength of a successful open source project lies in the collaboration of the developer community and in the continuous improvement of the codebase. If a company adopts and makes use of open source, then it simply has a responsibility to contribute to the community. To this end, QNX took over the Eclipse CDT project in June 2002.

The goal of the Eclipse CDT (C / C ++ Development Tools) project is to create a common set of interoperable C / C ++ development tools for the Eclipse platform. The Eclipse CDT has been marketed as an open source project, with management rights from the Eclipse Corporation. To launch the CDT project, QNX donated its development resources and source code to the QNX Momentics IDE project. Rational and Red Hat as community members also provided significant support to the project.

Rice. 1. Using the Eclipse platform, tool vendors can focus on the top level of the work stack, where real innovation is actually created.

QNX continues to maintain the CDT project, which has grown from an initially modest 80,000 lines of code to over 700,000 lines of code today. In early 2006, the Eclipse CDT Progress Log was an estimated 52% of QNX's contribution. Next came IBM with a 36% contribution. The CDT project is the second most popular Eclipse project after the Eclipse platform itself.

Can I afford to "gift" the code?

It may seem that "donating" your code means doing something contrary to common sense. However, if the functionality of your product turns out to be useful to apply, then why not contribute as a contribution to the open source community. By taking this step, you can benefit from this “standard” implementation offering along with the expertise to support the product. You will be able to benefit from the work of the entire community to improve the codebase. Such a strategy can free up your own resources to conduct additional research, focused on innovation, on adding additional functionality to your products.

Moreover, you could gain some control over the direction of the "standard" platform - earned, of course, thanks to your contributions to the community! If you support a project, behave like a good citizen of the community, respect other people's opinions, appreciate the input and advice of other members. Do not think that someone will try to "clean your pockets" as a result of using the code and intercept your leadership over the direction of the platform development.

For example, QNX Software Systems' strategy is to capitalize on the benefits of being a part of Eclipse while developing new functionality that plugs in through the standardized extensibility points already available in the Eclipse and CDT platforms. To this end, QNX intends to remain an active member of the Eclipse community, capitalizing on existing codebases and third-party developments (plug-ins), helping meet real-world customer needs by creating proprietary extensions. The described strategy is illustrated in Fig. 2.

Rice. 2. You can contribute to the work of the community with your own experience.

Benefits summary

The Eclipse-based tooling platform is mutually beneficial for both application developers such as QNX and customers who purchase the platform tools.

Developers benefit from less time to market and the ability to benefit from other people's research (at a low cost). These results may include high quality "clean IP" code provided by reputable vendors such as IBM and QNX. Another advantage for the developer is that he gets a simple and clear licensing scheme, including commercial rights and some patent protection. Moreover, the developer gets the ability to work on multiple OS platforms supported by Eclipse, as well as the extensibility points well-defined in the Eclipse project.

Customers buying an Eclipse-based IDE benefit from a tooling platform dedicated to embedded development, powerful cross-compilation support, easy debugging, and extensions to manage target systems. The client's development team will appreciate the many features that make work easier, the little time required for additional training, the good performance of the product, and a reliable platform to handle large projects. The client can also usefully leverage the Eclipse framework in their own applications (eg RCP, eRCP, etc.).

The future of Eclipse Corporation

The Eclipse Corporation is an active and energetic community. It continually introduces new projects, provides new architectures to established innovative companies, and even small companies can commercialize the Eclipse platform by creating new plug-ins at minimal cost that extend existing functionality (see Figure 3).

Rice. 3. Eclipse Corporation is a vibrant and rapidly growing community of plug-in developers.

Comparison of open source licenses

Not all open source licenses are created equal. QNX has taken a well thought-out move with the Eclipse Public License. This choice was dictated in part by the needs of its embedded customers and in part by a desire to take control of (and benefit from) technologies that differentiate products.

The not-for-profit Open Source Initiative () has come up with a helpful 10-point definition of open source. There are currently over 50 OSI approved licenses listed on the website, including the Eclipse Public License. These licenses may contain significant differences that need to be clearly understood. These differences can have a significant impact on the intellectual property (IP) of developers and their ability to protect it. This is especially true for the use of open source code (or derivatives based on open source code) in embedded devices.

Protective and non-protective license

Under the terms of a defensive license such as GPL v2, derivative work can only be redistributed with associated source code. Under the terms of the defensive license, it is guaranteed that when the source code is released to the open category, it will remain in that category in all subsequent generations and derivative works. As we will explain later, this requirement leads to certain problems in the case of embedded systems.

Examples of non-secure licenses are the original MIT and BSD licenses. Non-protective licenses retain the copyright of the owner, but grant broad rights to the user, including the right to modify and unrestricted free distribution (or personal use) of the software.

What is meant by a "virus license"

Some people call the GPL a "viral license". This name arose due to the ambiguity of the legal definition of the concept of "derivative development". With a strict interpretation of the definition, it turns out that even a small piece of code covered by the GPL is embedded in some proprietary application, then the entire application must be licensed under the GPL. An analogy with a virus immediately comes to mind.

Questions about receiving compensation

Recently, IP Indemnification has become the main topic of discussion for developers. In response, some open source vendors announced that they would protect customers from patent or copyright infringement lawsuits. And the newest open source licenses clarify penalties for users who try to assert their patent rights against other users of the codebase.

Top Challenges for Commercializing Open Source Software

Comparison of embedded and IT applications

The success of the open source industry has been fueled by the adoption of Linux by IT organizations. The benefits of using Linux were associated with running on relatively uniform and stable hardware (usually the x86 family) and using a flexible, resource-rich computing platform.

This is not the case with embedded software. The software runs on a wide variety of fixed-feature devices across a wide range of hardware architectures. Embedded device designers often base their competitive advantage on specific feature set, size, performance, cost, battery life, reliability, interoperability, and expandability. These distinctive features are usually implemented in low-level software, which in the case of Linux requires linking directly to the OS kernel. Customizing low-level software to meet customer needs is the norm, not the exception, so developers often get the functionality they need by changing the OS kernel. The method of direct linking is also used by embedding in code fragments in order to reduce the cost of creating libraries. This practice, taken together, makes it very difficult to protect proprietary code under GPL (publicly available) licenses.

Typically, these licensing issues do not apply to IT applications because proprietary, enterprise-specific software does not extend beyond the enterprise and is used solely for internal needs. On the other hand, embedded devices always distribute derivative software that qualifies for “force open” open source licenses, which could jeopardize key aspects of valuable open source offerings.

In addition, embedded products often have long lifetimes, both during production and use. An embedded product that is subject to the Open Source Terms of Use is at greater risk, including lack of long-term technical support, potential security issues, and IP infringement.

Licensing issues

Uncertainty of legal status

Despite the comforting words of proponents of some open source licenses, many of the key issues of concern to embedded systems developers have not yet been extensively verified by forensic practice. As mentioned, the definition of derivative work is key in enforcing certain clauses of the license, although many individuals and organizations who accept the open source terms of use have little or no understanding of the concept.

Some workarounds that allow commercial vendors to implement "proprietary" drivers in Linux (eg Loadable Kernel Modules) rely on "he said, she said" arguments rather than direct links to the text of the license agreement. In fact, such drivers that use LKM modules are fraught with dangerous circumvention of the requirements of the GPL license. Going to an extreme, one can interpret it to mean that the Linux codebase can be presented as useless for most practical uses, if some of these "proprietary" drivers are not included in it. This situation can effectively devalue the idea of ​​a GPL license.

Lack of compensation for IP infringement

In most open source use cases, there is a real possibility that you are inadvertently infringing on someone else's patent rights. Only a small fraction of open source licenses explicitly refer to patents, and no determination can be made on implied licenses. You must separately license any patents related to, for example, open source codecs that implement MP3 algorithms or other proprietary solutions. In the meantime, the bad boys (including Microsoft) are preoccupied with building a portfolio of patents that, according to many experts, can be "shot" at supporters of open source.

Some licenses explicitly refer to patents. For example, the Eclipse Public License explicitly mentions patent rights and contains a penalty clause if someone tries to assert patent rights differently. Eclipse also goes to great lengths to review the code and find out where it came from in terms of licensing, patent, or copyright law.

Additional Efforts to Preserve IP

To use open source, a company must spend considerable effort in the following areas:

• product distribution management;
• license management;
• resolution of legal conflicts in terms of clients' obligations;
• paying due attention to legal issues: maintaining the purity of IP rights, verifying IP rights for open source, establishing the source of the code, tracking changes in license versions, for example, GPL v3, etc.

Accepting customer requirements

Some large clients, faced with the complexity and uncertainty of open source software, refused to deal with open source products. If you do want to work with such customers, you must obtain or offer them to include terms for your code corresponding to the commercial license.

IP issues

Do the terms of your open source license affect the intellectual property that distinguishes your product? If so, your IP is at risk.

If your embedded systems use a mixture of your own software and open source software, then you must understand the nature, origin and relationship of all the components of the embedded software. Without such deep insight, you could inadvertently infringe someone's IP rights or even lose your rights to your own software.

With no patent licenses or compensation paid, the long-lived embedded software, the relatively high selling price and volume of fixed-feature embedded devices make such systems an obvious target for patent infringement claims from the bad boys and major competitors.

As the QNX Momentics IDE case study illustrates, there are many immediate benefits to open source software, including faster time to market, lower development costs, and more freedom to add features and innovation to your product. If you offer your software as a service that solves some problem for a client, then the client does not care whether you used open source software or not, he just pays for the function he needs.

However, you should understand the difference between different open source licenses and choose the one that suits your application and customer needs. Moreover, be prepared to answer for the licensing obligations of the software you have chosen. You should be aware of other IP requirements (such as patent rights) related to the software code. Be wary of a codebase that does not display an IP infringement message. Look for projects that offer compensation for possible damages and display an on-screen message about cash donations for developing code to compensate for costs associated with copyright or patent infringement, and so on. Also, make sure that the open source software you are using is consistent with your intellectual property policy and avoid defensive licenses that could force you to reveal distinctive pieces of your code. If your product is embedded in the system, then also consider offering commercial licensing terms for your IP.

The use of open source code in embedded devices leads to more complex problems than in the case of using such software in IT applications, since the first option is fraught with more dangers. Before deciding to use any open source software, estimate its true cost of ownership (TTCO) and its suitability for your project.

Finally, join the open source community of users and developers to maximize your value and benefit!