Chapter 13
Legal Decisions
I go to jail one time for no driver license.
—Bob Marley
When creating new works of firmware, it is important to consider both the incoming license terms (if not starting from scratch), and the distribution license terms and conditions. Examples include proprietary BSD and GPL. If creating a derivative work, it is important to consider all of this before starting the work so that time isn’t wasted developing something that someone else may claim later to be his or her private intellectual property (IP) or public IP based on association with the original license of the code used. As the work progresses, there cannot be ambiguity on the path or strategy used; code hygiene and discipline is key.
Often it is difficult for new software to be considered an island, and when it is not original, it is important to consider how and if the new software is statically or dynamically linked to older code in the final design. Beyond the technical challenge of combining old and new code, legally it can be very confusing. Developers are highly encouraged to get professional legal assistance from a quality source that has experience in software and patents.
Of course, if someone is in the business for a long time and the organization or team is steeped in either proprietary or general public license (GPL) ideology, then it is likely that team members will already know the rules; or at least what the rules were. New team members should be walked through the company norms. DO NOT ASSUME that the new smart people (and not so new smart people) who you hired will just know.
Also, as the law is somewhat fluid in nature, even if you are an old hand, it is very important to get fresh advice from a professional, because the terms can be nuanced. The nuances change from year to year without a great deal of advertisement to the broader community. The company may change their policies, etc. The following is an example of some of the basics, at the writing of this book. This is not a ruling by a judge, and this was not written by a lawyer.
Proprietary License
Under a proprietary license, the distribution and reusability rules are defined by the originators, but developers have to be very careful in how they define things. Terms can vary broadly. The people you license from will also be potentially interested in your licensing terms, and it may take each party’s lawyers many months to walk through everything and agree, should the need arise. This puts any development performed during the negotiation timeframe at risk of being unusable.
Many name-brand software packages come with forms of a proprietary license. While brand-name companies make money directly or indirectly with proprietary licenses, some forms of the proprietary license are in fact freeware (no-cost).
Berkeley Software Distribution (BSD) License
Under a BSD License, there are three versions to consider with varying degrees of compatibility between proprietary and GPL and other BSD licensed software. There have been multiple versions of the BSD license: four-clause, three-clause, and two-clause. The full license texts can be found online, but below are some key difference.
Key Four Clauses to the Original License
The following are the four key clauses of the original license:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <organization>.
- Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
The four-clause BSD license was not GPL-compatible, and the mandatory product message advertising the BSD developers was not wanted by product developers downstream.
Three-Clause BSD
The newer BSD License (three clauses) is compatible with GPL. The third clause appears below for comparison to the fourth clause above.
* Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
In addition to the three-clause version, there is also a simplified BSD license (two clauses) that is similar in that it is compatible with GPL where the third clause above was considered optional. The two clauses are as follows:
1.Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2.Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
One key benefit of the BSD license is that companies that create their own proprietary software can take BSD-licensed code to start with, create derivative works, or augment their existing code. Companies that create their own firmware or software regularly take the BSD drivers that are created by silicon vendors and weave their goodness into these “free” offerings. Intel® BLDK also uses a form of this license for the reused Tiano-based source code that it releases.
General Public License (GPL)
With GPL, software is considered free speech. It is free to use … but it has hooks in that you have to pass on that freedom of any derivative work or changes. The different versions of GPL spell out how free and how evasive that freedom level is on the rest of the system. For details, please see: http://www.gnu.org/licenses/gpl.html.
One of the chief complaints about the GPL third version is the “viral” like nature of the code base. If someone takes GPLv3 code and reuses it, the code base that it was used on may be considered to be GPLv3 as well, depending on one’s interpretation. For that reason, some prefer GPLv2.
Lesser GPL (LGPL)
The main difference between lesser GPL and GPLv3 is the ability to link to LGPL libraries by proprietary code bases without the “spider plant” effect of GPLv3 code. In nature, a spider plant is very easy to propagate from one place to another with just a small piece being transplanted. There are multiple versions of LPGL, which for the sake of time, I leave to the reader to research online.
Separating and Segregating Code
Mixing code covered by different legal agreements presents a challenge.
For example, linking between the GPL code and non-GPL code has been hotly contested. The concepts of dynamically linked versus statically linked versus not linked and the licensing hooks that then tie linked code to GPL are not clear at times, and this is a matter for the courts. Be extremely careful if you are shipping products based on GPL code, thinking through what you can/should/will do with that code and its availability to others after that ship date. Of course, it may be possible to never ship the software derived from GPL and to only use that code internally; then you would not have to reissue the code changes or make it available afterwards. Various manufacturers and their legal representatives have a varied view of GPL needs. Consult your lawyer.
It can be legally questionable to link GPL code to proprietary code, depending on the version of GPL and the terms of the proprietary code. This is exacerbated by terms in GPL v3, which has been referred to as “viral.” While that may or may not be friendly, GPL v3 does present challenges in that the attachment of GPL v3 code to a proprietary source code base puts the proprietary nature of the other agreement in question.
If the code is not linked dynamically or statically at build time, but executed through standalone interfaces as part of an operating system or shell or other industry standard, then clearly defined partitions between code entities can be maintained. One could have a proprietary first-stage boot loader, a GPL OS loader, and a BSD OS; and combinations of these.
Unlike the GPL-to-proprietary-code combination, it is much more plausible to link BSD code to proprietary code in that the BSD license allows for derivative works free of entanglements, and proprietary license would tend to govern the end solution.
While BSD seems like it would be a neutral option, linking BSD code to GPL code will bind the developer to hand back the GPL code if it ships. And if it is GPL v3, then the BSD code could be forced to act as if it were governed by the GPL.
Conclusion
Avoid cross-contamination of your products. From a legal point of view, it is important not to link BSD code (like that in Intel BLDK or Tiano), or any proprietary code (like a commercial BIOS) to GPL code (like Linux). It may help to keep GPL code firewalled and separated as much as possible, either physically or logically, from other code whose license types are such that one entity does not cross-pollinate with the other. Execution during one phase should know nothing about the next phase except where to jump to once that black box code is loaded. In this manner, there is no linking performed. It should be noted that some legal experts believe that linking is irrelevant and it is the actual intent that matters.
–Any non-GPL code would frown upon being linked at this point to any GPL v3 code.
–LGPL libraries, from reading through several references, appear to not have this linking problem that GPL code has.
–There are open-source tools to allow creation of a firmware image that concatenates the blocks into an FWH or SPI image such that it can be flashed or upgraded.
When looking at the debate between proprietary, BSD, and GPL licenses, it can be equated roughly to an in-depth political, ideological discussion. The rules can be drastically different. The viewpoints are as diverse as they would be between passionate and insightful people debating the merits and demerits of capitalism, socialism, and communism (respectively). And comparing the three, the analogy can play out along these lines. But when going from the theoretical to the implementation, the differences can make or break your solution.