The presentation reflects on French and Italian case law that, in recent years, has dealt with free software from two different angles: public procurement and consumer protection against joint sales of hardware and software.

• Open source is typically outside of normal commercial software procurement processes

• The Challenges

  • Increasingly diverse and distributed set of development resources

  • Little/no visibility into the origins of the software

• Supply Chain Comparison: Hardware vs Software

• Open source has revolutionized the mobile and device landscape, other industries will follow

• Supply chain management techniques from hardware are useful for managing software

• SPDX A standard format for communicating a software Bill of Materials across the supply chain.

• Effective management and control requires training, tools, processes and standards

Organizations across the globe are creating and distributing products that include open source software. To ensure compliance with the open source licenses, each company needs to evaluate exactly what open source licenses and copyrights are included – resulting in duplicated effort and redundancy. This talk will provide an overview of a new Software Package Data Exchange (SPDX) specification. This specification will provide a common format to share information about the open source licenses and copyrights that are included in any software package, with the goal of saving time and improving data accuracy. This talk will review the progress of the initiative; discuss the benefits to organizations using open source and share information on how you can contribute.

 One of the major changes introduced in the GPLv3 and LGPLv3 is the clause preventing “tivoisation”. Richard Stallman defines Tivoisation as “the practice of designing hardware so that a modified version cannot function properly.”. In this presentation we will go through the reasons of why the information installation requirement was introduced, how you can comply with this requirement and why you may want to think about it now rather than later.

Today, most software development teams use free and open source software (FOSS) components, because it increases the speed and the quality of the development. Many open source components are the de facto standard of their category. However, FOSS has licensing restrictions, and corporate organizations usually maintain a list of allowed and forbidden licenses. But how do you enforce this policy? How can you make sure that ALL files in your source depot, either belong to you, or fit your licensing policy?

A first, preventive approach is to train and increase the awareness of the development team to these licensing issues. Depending on the size of the team, it may be costly but necessary. However, this does not ensure that a single individual will not commit a forbidden icon or library, and jeopardize the legal status of the whole release... if not the company, since software is becoming more and more a critical asset.

Another approach is to verify what is included in the source repository, and check whether it belongs to the open-source world. This can be done on-the-fly, whenever a new file is added into the source depot. It can also be part of the release process, as a verification step before publishing the release. In both cases, there are some tools and databases to automate the detection process.

We will present the various options regarding FOSS detection, how this process can be integrated in the "software factory", and how the results can be displayed in a usable and efficient way.

With nearly 2,000 free and open source software (FLOSS) licenses, software license proliferation– can be a major headache for software development organizations trying to speed development through software component reuse, as well as companies redistributing software packages as components of their products.

Scope is one problem: from the Free Beer license to the GPL family of licenses to platform-specific licenses such as Apache and Eclipse, the number and variety of licenses make it difficult for companies to “do the right thing” with respect to the software components in their products and applications.

In addition to the sheer number of licenses, each license carries within it the author’s specific definition of how the software can be used and re-used. Permissive licenses like BSD and MIT make it easy; software can be redistributed and developers can modify code without the requirement of making changes publicly available. Reciprocal licenses, on the other hand, place varying restrictions on re-use and redistribution. Woe to the developer who snags a bit of code after a simple web search without understanding the ramifications of license restrictions.

 The enormous success of Linux in the consumer electronics industry has unfortunately led to a dramatic increase in license violations in devices. In this talk we will shortly look at the backgrounds of these violations, tooling to help uncover violations and what is needed to prevent future violations from happening.

 Industry and large Agencies needs “agile” programming resources, to reinforce their own development staff and take advantage of innovative approaches produced by “fresh minds” all over the world. At the same time they may be reluctant to engage in classical software development call for tenders and contracts. Such contracts are often “trusted” by large ICT firms, which will deliver according to their own rigid frameworks (often based on alliances with proprietary software vendors), may propose comfortable quality assurances, but will cover their (real) risks and liability with high contingency costs and will charge for any change request in case the original specifications have not fixed all possible issues. Introducing FLOSS in business implies a new contracting philosophy, based on incentives rather than penalties and liability. Based on 2011 experience with a large Space Agency, Patrice-Emmanuel Schmitz pictures the needed legal instruments for a novel approach.

This paper focuses on the use of FLOSS to promote vendor independence/avoid lock-in in the enterprise.  It looks at how FLOSS projects follow open standards, how forking prevents lock-in if a project threatens to migrate to a closed-source strategy and how FLOSS lowers the barrier to entry for SMEs wishing to implement and support software.  However it also looks at how the adoption of policies mandating open standards instead of FLOSS and how the success of cloud computing threatens to erode those benefits.  It discusses ways in which cloud computing can be adopted in the enterprise without forfeiting those advantages and urge corporate and government policy makers to mandate FLOSS rather than be satisfied with open standards.

The Free Open Source Software (FOSS) seem far from the military field but in some cases, some technologies normally used for civilian purposes may have military applications. These products and technologies are called dual-use.

Can we manage to combine FOSS and dual-use products? On one hand, we have to admit that this kind of association exists - dual-use software can be FOSS and many examples demonstrate this duality - but on the other hand, dual-use software available under free licenses lead us to ask many questions. For example, the dual-use export control laws aimed at stemming the proliferation of weapons of mass destruction. Dual-use export in United States (ITAR) and Europe (regulation 428/2009) implies as a consequence the prohibition or regulation of software exportation, involving the closing of source code. Therefore, the issues of exported softwares released under free licenses arises. If software are dual-use goods and serve for military purposes, they may represent a danger.

By the rights granted to licenses to run, study, redistribute and distribute modified versions of the software, anyone can access the free dual-use software. So, the licenses themselves are not at the origin of the risk, it is actually linked to the facilitated access to source codes. Seen from this point of view, it goes against the dual-use regulation which allows states to control these technologies exportation.

For this analysis, we will discuss about various legal questions and draft answers from either licenses or public policies in this respect.