Open-source

Third party libraries and applications

  • One of the advantages of embedded Linux is the wide range of third-party libraries and applications that one can leverage in its product
    • They are freely available, freely distributable, and thanks to their open-source nature, they can be analyzed and modified according to the needs of the project
  • However, efficiently re-using these components is not always easy. One must:
    • Find these components
    • Choose the most appropriate ones
    • Cross-compile them
    • Integrate them in the embedded system and with the other applications

Find existing components

  • Free Software Directory http://directory.fsf.org
  • Look at other embedded Linux products, and see what their components are
  • Look at the list of software packaged by embedded Linux build systems
    • These are typically chosen for their suitability to embedded systems
  • Ask the community or Google
  • This presentation will also feature a list of components for common needs

Choosing components

Not all free software components are necessarily good to re-use. One must pay attention to:

  • Vitality of the developer and user communities. This vitality ensures long-term maintenance of the component, and relatively good support. It can be measured by looking at the mailing-list traffic and the version control system activity.
  • Quality of the component. Typically, if a component is already available through embedded build systems, and has a dynamic user community, it probably means that the quality is relatively good.
  • License. The license of the component must match your licensing constraints. For example, GPL libraries cannot be used in proprietary applications.
  • Technical requirements. Of course, the component must match your technical requirements. But don't forget that you can improve the existing components if a feature is missing!

Licenses

  • All software that are under a free software license give four freedoms to all users

    • Freedom to use
    • Freedom to study
    • Freedom to copy
    • Freedom to modify and distribute modified copies

  • See http://www.gnu.org/philosophy/free-sw.html for a definition of Free Software

  • Open Source software, as per the definition of the Open Source Initiative, are technically similar to Free Software in terms of freedoms

  • See http://www.opensource.org/docs/osd for the definition of Open Source Software

  • Free Software licenses fall in two main categories

    • The copyleft licenses
    • The non-copyleft licenses
  • The concept of copyleft is to ask for reciprocity in the freedoms given to a user.
  • The result is that when you receive a software under a copyleft free software license and distribute modified versions of it, you must do so under the same license
    • Same freedoms to the new users
    • It's an incentive to contribute back your changes instead of keeping them secret
  • Non-copyleft licenses have no such requirements, and modified versions can be kept proprietary, but they still require attribution

GPL

  • GNU General Public License
  • Covers around 55% of the free software projects
    • Including the Linux kernel, Busybox and many applications
  • Is a copyleft license
    • Requires derivative works to be released under the same license
    • Programs linked with a library released under the GPL must also be released under the GPL
  • Some programs covered by version 2 (Linux kernel, Busybox and others)
  • More and more programs covered by version 3, released in 2007
    • Major change for the embedded market: the requirement that the user must be able to run the modified versions on the device, if the device is a consumer device

GPL: redistribution

  • No obligation when the software is not distributed
    • You can keep your modifications secret until the product delivery
  • It is then authorized to distribute binary versions, if one of the following conditions is met:
    • Convey the binary with a copy of the source on a physical medium
    • Convey the binary with a written offer valid for 3 years that indicates how to fetch the source code
    • Convey the binary with the network address of a location where the source code can be found
    • See section 6. of the GPL license
  • In all cases, the attribution and the license must be preserved
    • See section 4. and 5.

LGPL

  • GNU Lesser General Public License
  • Covers around 10% of the free software projects
  • A copyleft license
    • Modified versions must be released under the same license
    • But, programs linked against a library under the LGPL do not need to be released under the LGPL and can be kept proprietary.
    • However, the user must keep the ability to update the library independently from the program. Dynamic linking is the easiest solution. Statically linked executables are only possible if the developer provides a way to relink with an update (with source code or linkable object files).
  • Used instead of the GPL for most of the libraries, including the C libraries
    • Some exceptions: MySQL, or Qt <= 4.4
  • Also available in two versions, v2 and v3

Examples

  • You make modifications to the Linux kernel (to add drivers oradapt to your board), to Busybox, U-Boot or other GPLsoftware
    • You must release the modified versions under the same license, and be ready to distribute the source code to your customers
  • You make modifications to the C library or any other LGPLlibrary
    • You must release the modified versions under the same license
  • You create an application that relies on LGPL libraries
    • You can keep your application proprietary, but you must link dynamically with the LGPL libraries
  • You make modifications to a non-copyleft licensed software
    • You can keep your modifications proprietary, but you must still credit the authors

Non-copyleft licenses

  • A large family of non-copyleft licenses that are relatively similar in their requirements

  • A few examples

    • Apache license (around 4%)
    • BSD license (around 6%)
    • MIT license (around 4%)
    • X11 license
    • Artistic license (around 9 %)

  • Most of the free software projects are covered by 10 well-known licenses, so it is fairly easy for the majority of project to get a good understanding of the license

  • Otherwise, read the license text
  • Check Free Software Foundation's opinion http://www.fsf.org/licensing/licenses/
  • Check Open Source Initiative's opinion http://www.opensource.org/licenses

Respect free software licenses

  • Free Software is not public domain software, the distributors have obligations due to the licenses
    • Before using a free software component, make sure the license matches your project constraints
    • Make sure to keep a complete list of the free software packages you use, the original version numbers you used, and to keep your modifications and adaptations well-separated from the original version.
    • Buildroot and Yocto Project can generate this list for you!
    • Conform to the license requirements before shipping the product to the customers.
  • Free Software licenses have been enforced successfully in courts. Organizations which can help:
  • Ask your legal department!

Keeping changes separate

  • When integrating existing open-source components in your project, it is sometimes needed to make modifications to them
    • Better integration, reduced footprint, bug fixes, new features, etc.
  • Instead of mixing these changes, it is much better to keep them separate from the original component version
    • If the component needs to be upgraded, easier to know what modifications were made to the component
    • If support from the community is requested, important to know how different the component we're using is from the upstream version
    • Makes contributing the changes back to the community possible

  • It is even better to keep the various changes made on a given component separate

    • Easier to review and to update to newer versions

  • The simplest solution is to use Quilt

    • Quilt is a tool that allows to maintain a stack of patches over source code
    • Makes it easy to add, remove modifications from a patch, to add and remove patches from stack and to update them
    • The stack of patches can be integrated into your version control system
    • https://savannah.nongnu.org/projects/quilt/
  • Another solution is to use a version control system
    • Import the original component version into your version control system
    • Maintain your changes in a separate branch

results matching ""

    No results matching ""