(1) Using open source code can help companies save time and money by leveraging existing "heavy lifter" components rather than reinventing them. (2) Companies must balance using existing open source components with contributing back upstream to gain benefits like access to ongoing improvements and meeting license obligations. (3) Complying with open source licenses is important for companies distributing code and involves understanding obligations like including copyright and ensuring access to source code.

1. Fundamentals of Using Open
Source Code to Build Products
Brian Warner
The Linux Foundation

2. The Linux Foundation
Linux Foundation Confidential 2

3. The Linux Foundation is the center of Linux
development, legal defense and promotion
3

4. The Linux Foundation is Represented by
Firms with Major Investments in Linux
Platinum Sponsors Gold Sponsors
Linux Foundation Confidential 4

5. The Linux Foundation is Represented by
Firms with Major Investments in Linux
Silver Sponsors
Linux Foundation Confidential 5

6. The Linux Foundation by the Numbers
Ø 1 Linux kernel inventor – Linus Torvalds
Ø 170+ Corporate members including IBM, Intel, Samsung, Oracle, NEC, Fujitsu,
Qualcomm, HP, Red Hat, Canonical, China Mobile, Motorola, AMD, ARM, and
many more…
Ø 3,000,000+ visitors each month to our web properties
Ø 15,000+ registered users on Linux.com
Ø Thousands of individual members
Ø Dozens of technical workgroups include the Tizen Project, Yocto Project, Long
Term Support Initiative, Open Compliance Program, Linux Standard Base,
Linux Printing, Legal Collaboration, etc.
Ø 23 industry-leading training offerings
Ø 14 Global Linux events – the “Who’s who of Linux”
Linux Foundation Confidential 6

7. Members Create Workgroups to Collaborate
with Other Members
Driver Backporting Open Source as Prior Art Kernel.org Staff
Green Linux Japan SI Forum Developer Travel Fund
Developer NDA Program IPv6 Workgroup Technical Advisory Board
Legal Defense HPC End User Council
Linux Foundation Confidential 7

8. The Linux Foundation is at the center of the
Linux Defense Network
LINUX DEFENDERS
Linux Legal Defense Fund
8

9. The Linux Foundation offers training and
technical services
9

10. Fundamentals of Using Open Source Code to
Build Products
Why do it?
The (corporate) open source development
model
Understanding your obligations with open
source licenses

11. Open Source Software is ...
A licensing regimen
A collaborative development methodology:
Ø Community develops, debugs, maintains
Ø Usershave source code access and the right to adapt,
distribute
A way to reduce development costs and
improve quality
An inexpensive way to distribute software
An inexpensive way to procure software
11

12. Incorporating open source components
Why do it?

13. The easy answer:
To save time.

14. The easy answer:
To save time and money.

15. The more complicated answer
Time to money.

16. Time to money is impacted by five major
factors
1. Time to produce a sellable product
2. The cost to develop or acquire components
3. Competitiveness of a product’s features
4. The quality of the product
5. Ability to provide a stream of updates

17. 1: Time to Produce a Sellable Product
Rule #1:
Ø There
is little value in reinventing the wheel (and it’ll
probably make you late).
Rule #2:
Ø Evaluate external components. If the shoe fits, wear it.
Rule #3:
Ø Get it for free when you can.

18. A typical software stack can be partitioned
into two broad categories
Heavy lifters Differentiators
OS kernels Performance tweaks
Web browser engines Applications
UI toolkits Integration
X servers Fit and finish
Multimedia frameworks …
Bluetooth stacks
Telephony stacks
…

19. Try not to reinvent the heavy lifters
They’re done.
They’re mature.
They’re open.
(and your competitors are already using them
to get a leg up on you.)

20. 2: The cost to develop or acquire components
As of 2011, it would cost at least $3B to develop
the Linux kernel from scratch.
On average, 7.21 patches are accepted into the
kernel per hour.

21. 2: The cost to develop or acquire components
The amount of combined effort going into open
source “heavy lifters” is astonishing.
We call this the leveraged development model.

22. 2: The cost to develop or acquire components
You can work against it, or you can work with it.

23. 2: The cost to develop or acquire components
Did I mention it’s free?

24. 3: Competitiveness of a Product’s Features
Less time spent on heavy lifting means:
Ø More time spent on competitive differentiators
§ - Or -
Ø Competing in-market sooner with the differentiators you
already have
Heavy lifters are (usually) continually improved
Ø …and often by someone else.

25. 4: The Quality of Your Product
Linus’ Law:
Ø “Given enough eyeballs, all bugs are shallow.”

26. 5: Ability to Provide a Constant Stream of
Updates
Thanks to these two phones…
…consumers in all industries are far more
aware of system software updates
than ever before.

27. Updates are hard
Has your development talent shifted to new
products?
Do you have time and resources to backport?
Will the features be competitive enough to
instill brand loyalty?

28. These are real issues
There is no silver bullet, but it helps when the
code base hasn’t been static.
-longterm stable releases were created to
address this problem.
LTSI is a kernel specifically for CE devices.

29. Understanding the (typical) corporate open
source participation model
When should you tap into an ongoing
development process?
How do you balance short and long term value?
Do you need to contribute back?
Can you effectively manage your license
compliance obligations?

30. When do you pull code?
Continuous integration and testing is a
hallmark of many open source projects.
Features are often submitted early and stabilize
over time.
Roadmaps are not binding.

31. When do you pull code?
First, understand the cycles.

32. Open source development model
User
Community
Project or Feature Ideas
Architecture and Feature Requests
Design Discussion (submitted by developers
and users)
Implementation
(coding)
Patches
(submitted by developers
and users)
Continuous Testing Deployment
and Integration (release)
Developer
Community Test Projects to Automate Maintenance
Testing and Validation

33. The open source release cycle
Validate Build
Generate Integrate QA
Build
patch with -dev validation
Release
Debug Submit Validate
validation
Feedback
Loop Publish as
Write code
-stable
Check out
code
Setup
machine
Driven by participating developers Driven by maintainers

34. How to understand the cycles
Research a project’s historical release cycles.
Subscribe to project mailing lists.
Identify maintainers, and what makes them tick.
Bug/feature trackers often have future
milestones.

35. Balancing short and long term value
Product development is a journey, not a
destination.

36. 100% short term value

37. This is not always a viable path
The way your differentiators interact with heavy
lifters will change over time.
Ø New or deprecated features in upstream heavy lifters
§ Or -
Ø API changes
§ Or -
Ø Customer requirements
§ Or -
Ø …
Ask Google…

38. So… what then?
The current industry best practice is to balance
consumption with upstreaming.
Choosing what goes upstream is an art not a
science, but it’s usually the heavy lifters.
Upstreaming is not a requirement (though it is a
good way to save money and gain respect).

39. Don’t confuse upstream contribution with
license compliance
Upstreaming is a development strategy.
License compliance is a legal requirement.
(but contributing upstream is a good strategy to
meet most compliance obligations)

40. Speaking of license compliance
That sounds all legal and stuff…

41. Speaking of license compliance
It is.

42. Standard Disclaimers
The presenter is not a lawyer and none of the
material discussed or presented should be
considered as legal advice.
Please consult with your corporation's counsel
for your specific situation.
42

43. What Makes a License an Open Source
License?
The Open Source Initiative formulated an “Open
Source Definition” (OSD) to define the criteria
that a license must meet to be considered
“open source”
Ø Free redistribution
Ø Availability of source code
Ø Right to modify
Ø No discrimination (against users or uses)
Ø Self-perpetuating terms and conditions
43

44. What is “Open Source Compliance?”
Open Source Compliance refers to the aggregate of
Ø Policies
Ø Processes
Ø Training
Ø Tools
that enables an organization to effectively use open
source software and contribute to open
communities while
Ø respecting copyrights,
Ø complying with license obligations, and
Ø protecting the organization's intellectual property and that of
its customers and suppliers.
44

45. When do I need to think about compliance?
If you are distributing code covered under an
open source license.

46. Define “distributing”
“Distributing” typically means transferring
control away from yourself or your company.
Ø (but ask your corporate counsel)
Internal use code is sometimes distributed
down the road, so it should be considered too.

47. Generally speaking, what’s an obligation?
Depending on the license(s) involved, obligations
could consist of:
Ø Inclusion of copyright and license in the source code and/or
product
Ø documentation or user interface, so that downstream users
know the origin of the software and what their rights are.
Ø Disclaimers of warranty on behalf of the authors
Ø Notices as to source code availability – for original work, for
combined work or modifications, and so on
Ø Etc.
Your corporate counsel needs to interpret this for
you.

48. Individuals Worldwide Commit Themselves to
Compliance Activities
From the September 26, 2010 NY Times:
http://www.nytimes.com/2010/09/26/business/26ping.html
48

49. Managing an effective compliance program
Legal lays the ground rules (interpretation,
combinations, blessed/banned licenses).
Everything else is logistics.

50. Managing an effective compliance program
Logistics is probably >90% of the work.

51. Compliance in a nutshell
Know what license combinations are approved.
Have a consistent process for rapidly approving
new components.
Keep detailed records of what you do to the
components you ship.
Fulfill the obligations of the license.
Be prepared to respond to inquiries efficiently.

52. Don’t panic
We offer training on this.

53. There are a lot of resources out there
https://www.linuxfoundation.org/publications/compliance
http://www.softwarefreedom.org/resources/

54. Conclusion
Open source is effectively springboarding the
companies whose engineering and management
organizations know how to use it effectively.
There’s a lot of money to be made and saved.
Complying with open source licenses is really
important.
Compliance is an ongoing process.
When in doubt, find your lawyers and ask them.