Linux distribution and the use of open source projects and packages

Use Of Open Source Software Projects

As you already know, the Linux distribution used in an embedded project, or for that matter any Linux distribution, includes more than the kernel-although technically, the Linux project consists of only the kernel. The kernel's job is managing system resources and running user programs; from your perspective, the value of the device is the problem that the application running on the device solves. This article goes into detail describing how to use open source packages in your project. This article describes how an open source project is organized from a technical and personnel perspective. There is also a part dedicated to describing how to build and install the source code offered by an open source project. A note about licensing: a project that suits the technical requirements for your application sometimes can't be used due to licensing issues. Before deciding on a package, make sure you understand the license terms and conditions and that you're ready to follow those terms to the letter and in spirit. Along with licensing, this article also talks about who is involved in an open source project and what roles they fulfill. Last, you survey the packages that embedded developers frequently use. These packages are just a sampling of what's available and commonly used; there are literally thousands of open source projects, with new ones being started every day.

Using Open Source Packages

It's important to see the big picture when you're using an open source project. The mechanical steps are easy enough: getting the source and compiling it for your board. But remember that open source is about participation: as a user of open source software, you're a part of the project, not just a consumer of the software. When you can, help with the success of the project. Being part of an open source project involves the following:

Understanding the licensing: This is an important step. There are many different types of licensing options; the GPL is just one. Although most open source licenses are compatible with commercial projects, you need to do your due diligence.
Getting the source code: More and more projects are moving away from the tar archive as a distribution system and are instead using a source control system as a way of making the project sources available. Even if the project uses a source control system as the primary way of distributing the source files, tar archives are still available for the traditionalists.
Building and installing the code: This consists of two steps: a configuration step and the build. Not all packages have a configuration step; in that case, you need to run make to cross-compile. Because Linux has gained in popularity for embedded systems, you can cross-build most tools used to build open source projects, as well as the projects themselves, by passing the right parameters into the build tools.
Participating: Open source means you're welcome to participate in the project by contributing patches, reporting bugs, or maybe answering a question or two.

You're part of the project as a user and not a passive consumer of the code; however, you're always welcome to ask for help.

Open Source Project Structure

An open source project is as much about the people as it is about the code. Every open source project has one or more leaders, called maintainers, who are responsible for coordinating the activity on the project. The maintainer sets the direction of the project and is responsible for getting the code in such a state that it can be released. Working on the project are any number of developers who crank out new features and functionality or fix problems. For a smaller project, the maintainer and the developers may be the same set of people or a single person. The maintainer has control over the project by approving all changes to the code. By controlling what code goes into the project, the maintainer effectively controls the technical direction of the project. For larger projects, some developers are granted the right to accept code and make it part of the project without the maintainer's permission; these people are called committers, because they can commit changes to the version control system.

Of course, each project has its own organizational quirks, but they follow this basic template. Communication occurs via a mailing list and, with increasing frequency, IRC channels. The project has at least one mailing list; larger projects have mailing lists that focus on different areas of the project. The project also has some sort of system for tracking tasks and defects.1 All of these project tools are hosted on a web server, and the project has page with links so you can find the tools and resources. As a person using the code in the project, one of the things you need to do when evaluating the project is to read the mailing list and bug reports to see how other people use the project and what sorts of questions arise. As other people get help on the mailing lists and IRC channels, they may get an answer for a problem you encounter. The amount of traffic on the mailing lists will give you an idea of the activity level around a project; a project that hasn't had a posting on a mailing list in three months probably doesn't have many users.

The maintainer decides whether the code is in good enough shape for a release. Larger projects have a phase that lasts a few weeks during which the code is frozen except for changes that affect the coming release. When the code is deemed ready, the sources are tagged in source control for retrieval at a later date, and the files are assembled in to a tar file and placed on the project's web site for downloading. Work then begins on the next release, and the cycle repeats. Unless you need cutting-edge code (such as a feature that isn't present in the current release), you're likely to use the code that has been tagged or otherwise packaged for release.

The Project Team Isn't Your Extended Workforce

Users make lots of requests for the project to fix bugs in a certain order or make other enhancements to the project. The engineers working on the project and the maintainer take these into consideration when planning, but won't do them right away just because you have a deadline. As a participant in the project, if you need some functionality, be prepared to contribute in a meaningful way: help with the design, coding, or testing, and the chances of that feature or bug being completed will increase dramatically. The same principle applies with bugs as with features. If you encounter a problem, put forth the effort to explain the problem clearly; if possible, write some code to reproduce the problem. If you can, look at the source code and try to find out why the problem is happening so you can offer help with finding a solution. Your efforts, even if they don't solve the problem at hand, are worthwhile and appreciated. Open source is about participating, and the more fully you participate in the project, the better the result for everyone. That said, many embedded project teams accept commercial engagements for new features and support. For those working on commercial projects, if you need work done by a certain date and have the funds, soliciting the project maintainer for a contract is the right avenue to take. Many project teams support themselves by doing contracting work, and your financial support will help them to continue to improve the project as a whole.

Understand the Licensing

Each project has its own licensing terms. As a user of the software, you're obligated to abide by the terms. The software that solves a technical problem perfectly may not be the right choice for the project because of the licensing around the software. Make sure the license works for you before deciding on a package, because the cost of switching increases greatly as the project moves forward. Permissive vs. Restrictive Licenses You'll notice a pattern in open source licenses: restrictions on how the code can be used in one project may incense users of another project or product. For example, a company can take public domain code, incorporate it into their product, and then use a closed-source license. Although that isn't in the spirit of open source, this is completely permissible and well within the rights of the company. With the GPL, you must always use the GPL license for that code or code derived thereof. This is called a restrictive license because the code can't be offered under a different license. This provision is why so much effort has gone into deciding exactly when and how code is derived from other code. In the simplest case, the code base that results from adding or changing a GPL project is unambiguously a derivation of an existing work and therefore must be licensed under the GPL.

The subtle cases result in the most argument, because the language of the GPL license leaves room for interpretation. All of these licenses limit your rights to sue the creators of the software it if fails for any reason; this provision is common for commercial products, not just software. The licenses all claim that the software is provided as-is and isn't fit for any particular purpose. This is legalese that you'll find in nearly all software contracts; it's a way to limit the seller's liability to the purchase price of the software. Of course, this isn't legal advice; consult with an attorney specializing in intellectual property during your project to understand exactly the rights and obligations of each licensing method. If you're creating work for customers as a consultant, please make them aware of how the code you used was licensed.

Common Licensing Types

The following are the most frequently seen licensing types. This is, of course, just a sampling; many different licensing schemes are in use, because all you need to do is modify an existing license or write a new license document to create a new license. There is no authority-nor should there be-over what licenses should be available for use:

Public domain: This is the most liberal (least restrictive) type of license. It means the software can be used by anybody for any purpose without attribution or payment. You can make changes to the software as you like. You can take the software and relicense it under different terms. A bit of trivia: all software written by the United States government is public domain.
Apache: The Apache license applies to all software created by the Apache Software Foundation. Users of Apache licensed software can use the software and must keep attribution in the source files. You can offer the software under different licensing terms, but it must maintain the attribution.
Berkeley Standard Distribution: This is a very liberal license that is much like Apache License. You may use the software and offer it under different licensing terms as long as you retain the licensing notice in the source files and include attribution in the user documentation. A special clause in the license prohibits using the names of organizations or anybody who worked on the software as an endorsement without prior permission.
GNU Public License: This is the license that many closely associate with open source software. The GPL is more restrictive that other licenses in that is governs derived works-when code is licensed as GPL, modifications and additions to the code also become licensed under the GPL. This is why you may have heard the word viral in conjunction with this licensing scheme. Volumes have been written about what, exactly, constitutes a derived work; the quick rule of thumb is that if you link to the code and GPL binaries are included in your code, you've created a derived work. The GPL license further specifies that you make available the source code to anyone who receives binaries. This doesn't mean you must supply the source code to anyone who asks for it, just to those to whom you provide a binary.
Lesser GNU Public License (LGPL): This license is a less restrictive variant of the GPL. The Lesser GPL doesn't have the idea of a derived work, and by linking your code to a LGPL project, you code doesn't also become licensed under the LGPL. This means that if you get a LGPL graphics library and link into it, your code can be licensed any way; it can even be closed source. However, if you make changes to that library, those must be licensed under LGPL, and the source code for the library (not the entire software project) must be made available to your customers. The LGPL license exists for projects that wouldn't be used due to the derived work licensing of the GPL. Presently, the GNU Standard C library is licensed under the LGPL, so just compiling a program with a GNU C Compiler using the GNU Standard C library doesn't make it automatically covered by the GPL.
zlib License: This license is like the BSD or Apache licenses in terms of redistribution and use of the code. Unlike the BSD or Apache licenses, you must state that the code was created by the original programmers, and you may not remove any of the licensing information from the source files. Furthermore, if the source file is changed, you must make it clear by putting comments in the source code. You must also include a note in the documentation stating that you're using zlib licensed code.