7th December 2005, EUROCONTROL-EEC, Bretigny-Sur-Orge, France
Working with OSS Licences in PHILIPS
by Arnoud Engelfriet, PHILIPS
Overview
The IP department of PHILIPS has been working with OSS for the past 4 years. We'll discuss how PHILIPS use open source in products, mainly in consumer electronics, and what we did to get the rules right, and to make sure everyone is following them. We'll also discuss how to make effective choices concerning open source -- what to open source, when and when not to open source your software.
Let's first review the main open source licenses, and avoid loaded vocabulary like 'viral'.
- free-for-all licenses, like the BSD, are simple: just give credit for the original software, and use it however you wish.
- keep-open licenses, like the LGPL and the Mozilla license, allow you to combine them with other code under other licenses, but require that you give back any modifications you may make to the open source code.
- share-alike licenses, like the GPL, that require you to contribute not only the code to modifications, but the code to extensions as well.
F. Gasperoni: You must only release your code if you distribute products based on the modified code. If you do not distribute the modified code, but only use it internally, you do not have to release your modifications. >Franco>
A. Engelfriet: PHILIPS, of course, sells its products to millions of people, and does fall within the distribution requirements. >Arnoud>
F. Gasperoni: EUROCONTROL uses ATM systems that are not sold to the general public typically. >Franco>
A. Engelfriet: Indeed, if you are going to use it internally for your organization, that's fine: you do not have to tell anybody, you do not have to share anything. However, I am approaching this from the point of view of a distributor. >Arnoud>
P. Johnson: Even PHILIPS can use and modify Linux internally. >Paul>
R. Schreiner: What is "internal" in this sense? >Rudolf>
A. Engelfriet: That's a very good question, especially for a multinational company. >Arnoud>
F. Gasperoni: The reason why people do not like the word viral, is that if you PHILIPS decide to take Microsoft Windows and put it into your product, viral or not viral, you couldn't do that, full stop. >Franco>
Therefore, while the technical people in the company do not have to know the details of the different licenses, they do have to know the potential impact of choosing to use software with a share-alike license.
PHILIPS use open source in products, mainly in consumer electronics, like hard disk DVD recorders, universal remote controls, and web tablets. Our new line of wirelessly connected devices, Connected Planet, has many devices on embedded Linux running 802.11 wireless communications for audio and video streaming. PHILIPS also develops chips like the Nexperia line, with their compiler, tool chain, and Linux ports all available.
The main reasons for Open Source usage in PHILIPS is cost reduction and faster time to market. It's very seductive: developed, useful code for free. We're looking at making our use of open source more systematic, and are examining the possibility of releasing some of our own code as open source. Before committing to using open source, we decided to first establish an open source policy.
An open source policy is necessary because suppliers and customers are increasingly using OSS, and OSS can have an impact on PHILIPS' intellectual property rights. For example, PHILIPS holds many patents, which they do not want to license for free. Using open source can imply certain patent obligations, which will have an impact on the patent holder. We want to be sure we know what we're doing, and when we're doing it. It shouldn't be a decision by the individual engineer; it must be taken at the product design level.
F. Gasperoni: Arnoud, is it considered distribution if you sell a VCR with embedded OSS? >Franco>
A. Engelfriet: It would most definitively. >Arnoud>
F. Gasperoni: Because one question that was asked is: what if I put some GPL software on a missile. The question that was asked to Stallman is "Is this considered distribution?" The answer was: "Of course, not". >Franco>
A. Engelfriet: If you are a missile dealer, and you sold it, then it is a distribution. >Arnoud>
P. Johnson: If a missile manufacturer sells to the DoD, that is a distribution. >Paul>
A. Engelfriet: The DOD has the right to demand source code. >Arnoud>
O. Robert: You could put the source code into the missile ;-) >Ollivier>
F. Gasperoni: It's the same for the source code inside the VCR: it is in the ROM. >Franco>
A. Engelfriet: Of course, it must be accessible to the outside world. We have a product with a hard disk, and we put the source code of Linux on the hard disk. If you read very carefully to the documentation (but nobody does that) you will see that this product uses Linux and it is there on the hard disk. For other products, we have a CD-ROM for documentation where the source code is included. >Arnoud>
This is an interesting support issue: clients may wonder why there's 20 MB of disk space used, when they want to record on that space. Few people are going to bother and that's a practical frustration for the product managers: they say that nobody wants the source code. The important thing is that the source code is there, as required by open source licence compliance, available to anyone who wants to use, study, modify and improve it.
P. Johnson: Could it be on a web site? >Paul>
A. Engelfriet: You cannot actually. The licence says either you ship it or you make a written offer to give it to anybody who writes to you. The source code has to accompany the product. GPL version 2, article b), section 3) states that if we put a binary on the product, the source code must accompany the product. >Arnoud>
Anyway, PHILIPS' policy on open source allows unrestricted use of OSS internally. What tends to happen is that an internal research prototype becomes a product. So be careful with that.
PHILIPS is a company that manufactures and commercialize products; the use of OSS in products is fine as long as it does not involve differentiating technology, i.e. an added value feature, and if it does not open valuable patents. We use open source only where it makes sense for us.
If we release something in open source, it has to benefit both PHILIPS and the community; There is no point in starting a competitor to an existing open source project.
Finally, every decision about OSS must be taken jointly by the IP&S and the Open Source Advisory Board.
Engineers will put open source in products, suppliers will ship open source, even without you knowing it, and end users will combine existing code with open source. Your own developers may participate on outside open source projects; you must be prepared to deal with that. It's thus vital for the company to have a clear vision of the implications the use of Open Source might have in terms of legal aspects.
You can benefit from open source. There are two general ways: consumption or participation.
You can decide to buy some software from a third party, you can write some yourself, and use open source for others. You can even decide to buy open source from a third party, for the support they provide. This is passive use of open source.
More proactive use might involve participating in an open source project, for example to make it work on your embedded product. You can then contribute those patches for common maintenance, and adopt this existing project. You can also start your own open source projects, and build community around them. This can be a lot more powerful, since you can share costs and contributions, however it requires more discipline: you must be prepared to expose your code for the world to see.
Once you have a policy, you will need a review board to examine and decide on each individual case. You need a place where people can come and ask what is allowed and what is not. Set up a group which can represent all your business units or product divisions, and preferably also involve the legal and IP departments, to consolidate your expertise in this area. You may want to set up set up liaisons with purchasing, customer services, PR communications and HR. For instance, if we hire an open source engineer, he could be in trouble if the contract says that everything he writes is owned by PHILIPS . Also, the customer service flowcharts must include answers about the source code provided on the CD-ROMs.
The OSS policy should actively address both customers and suppliers. By default, the contracts clauses should be "Don't give us any OSS and don't make our software OSS". This must be clearly stated and standard contract clauses should be created to address this issue. While this may seem draconian, it really is necessary to get people thinking about what they're really doing. If there must be an exception, it's clear, transparent, and documented from the onset.
Open source usage by subcontractors can have unexpected implications, even with free-for-all software: learning too late that some subsystem incorporates BSD licensed code could require reprinting all the documentation to add the credit notices. You must determine how you will distribute the source code, with a web site, or keep a stack of CDs in customer service to send to those that request it, or by distributing the source with the device.
When you use open source in products, you must first determine where you should use it. We can classify product features into 3 different groups, and determine what level of open source is appropriate.
- Differentiators provide added value to your product by unique features. This type of software should be kept closed, for maximum market advantage.
- Baseline features provide the necessary functionality to meet market demand. Use a case-by-case approach to decide whether to make, buy, or use open source.
- Commodity features are essentially invisible to the user. Using open source saves time, effort, and money.
We can now walk through an example of open sourcing decisions in a product that PHILIPS developed: the Active Block IO Scheduling System (ABISS) scheduler. The underlying idea is to have a disk scheduler which you can ask to give you a guaranteed disk access bandwidth for a real-time video or audio stream. The scheduler either returns a guaranteed bandwidth stream, or it tells the caller that the requested disk bandwidth is not available. This significantly enhances the design of a hard disk recorder or video player.
This project was the first in which we deliberately decided exactly which license we would for each component. The system rides on the GPL Linux kernel. Kernel modules which link into it must be GPL as well. The actual kernel module which must be GPL can be kept simple, however, if the functionality of the system is broken into smaller modules. Then each sub-module can be licensed corresponding to its function value as differentiator, baseline, or commodity feature. Thus some modules, like the scheduler and special optimized policies, were kept as proprietary, unreleased code. The kernel module itself was released under the GPL, and the application interface and the userspace policy daemon were released under the LGPL, requiring only redistribution of modifications to the original code.
In this case, the technical architecture was deliberately designed with licensing considerations in mind, and as a result does not require the release of valuable proprietary IPR which implements differentiating software features. Technical choices have to be made with interaction between designers and legal people to ensure that the architecture does not influence your legal options. This requires people who understand both technical issues and law.
Discussion
from 28'00" to 32'00" (4'00")
M. Michlmayr: For your DVR, you obviously had to make changes to Linux, and because of GPL you had to make these changes available. Did you actively try to integrate theses changes with the Linux kernel? Do you have anything in your policy to address this issue? >Martin>
A. Engelfriet: Actually, our policy actually says that if the project would benefit from the changes, we should give these changes. If they are specific to one of our products, that doesn't make sense. >Arnoud>
M. Michlmayr: Do you take the long-term effects into consideration? If the changes are not integrated with the Linux kernel, in a few years time, the work will have to be done all over again. >Martin>
A. Engelfriet: There is a conflict of interest there: the product must be out of the door as soon as possible but, on the other hand, there is the opportunity of doing something that represents a long-term benefit for the company and the community in general. >Arnoud>
M. Michlmayr: How do you cope with that? >Martin>
A. Engelfriet: With great difficulty. We try to work together with other companies in the Consumer Electronics (CE) sector. We have several common projects, among which the CE Linux Forum. This project aims at improving Linux in the context of the CE industry, to achieve faster booting times for example. We share costs and the developments on a common kernel. >Arnoud>
F. Gasperoni: How does this cooperation work? >Franco>
A. Engelfriet: Pretty well. However, it is not so easy to move from a proprietary model to an open-source model. For some, it's quite difficult to share resources with competitors. There is also a lack support from the open-source community in general, but that's because we are in a very specialized niche. There's a vast cultural gap between the world of consumer electronics and the world of PCs. PC guys are often discouraged by the constraints of the CE industry. CE versus PC, it's a difficult match. >Arnoud>
Salient points
- Open source licenses can be usefully classified into free-for-all, keep-open, and share-alike licenses.
- Share-alike licenses require distribution of the modified source code along with the binary image in the device's firmware, or at least making the source code available on written demand. PHILIPS deliberately complies fully with license requirements and ships the full GPL and LGPL code, either on the device hard disk, or as an accompanying CD-ROM.
- The main reasons for Open Source usage in PHILIPS is cost reduction and faster time to market.
- An open source policy is necessary because suppliers and customers are increasingly using OSS, and OSS can have an impact on PHILIPS' intellectual property rights.
- PHILIPS' policy on open source allows unrestricted use of OSS internally, but the use of OSS in products is a completely different issue.
- OSS should be used only if does not involve differentiating technology, i.e. an added value feature, and if it does not open valuable IPR.
- Every decision about OSS must be taken jointly by the IP&S and the Open Source Advisory Board.
- You can benefit from open source by using it. More proactive use might involve participating in an open source project.
- By default, the contracts clauses should be "Don't give us any OSS and don't make our software OSS".
- The technical architecture can be deliberately designed with licensing considerations in mind, and as a result will not require the release of valuable proprietary IPR which implements differentiating software features.
"Whether you know it or not, your engineers are using Open Source."
 |
 |
 |
 |
| abstract | slides | MP3 | OGG |
