best practices using open source software in commercial products bill stoddard

Best Practices using Open Source Software in Commercial Products

Bill Stoddard

ApacheCon Europe 2007

2

Agenda

What is Open Source?

Legal

Community

Service Stream Maintenance

Final Thoughts


3


License Few restrictions on redistribution and use OSI Certified: http://opensource.org/docs/certification_mark.php

Community Community is build around code and is more important that code Values transparency, free exchange of ideas & individual innovation Shared goal(s) Geographically diverse

Collaborative Development Methodology Shared information space (revision control system) Shared communication (mailing lists, wiki) Governing processes (conflict resolution, legal vetting, admitting new ‘trusted’

members, organizational continuity that outlives individual community members)


4

Questions to ask

How will the OSS be used? ISV, IT vendor, reseller – create new business opportunities Accelerate open standards adoption Consulting & Services Subscription/Support

Will you redistribute the OSS?

Will you package OSS with proprietary extensions?

How will you support the OSS?

Will you become involved in the developer community?


5

Agenda


Legal

Community


Final Thoughts


6

Legal

Caveat

I am not a lawyer.

This is not legal advice.

This information is intended to give you context in conversations with your legal team


7

Legal

Two questions

Q1: Does the license allow you to do what you want?

Q2: Are you certain?


8

Legal

But what you really need is….


9

Legal

Due Diligence

Method for investigating source code provenance

Hard work


10

LegalDue Diligence Step 1

Know your supplier

Apache Software Foundation

Codehaus

Sourceforge

Usenet posting

Look for code contribution guidelines

Contributor License Agreements (CLAs)

Click-thru JIRA submissions


11

LegalDue Diligence Step 1 cont… (snip from ASF iCLA)

You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Foundation….

1. Definitions. "You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with the Foundation. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Foundation for inclusion in, or documentation of, any of the products owned or managed by the Foundation (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Foundation or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Foundation for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."

2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.

3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.

4. You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Foundation, or that your employer has executed a separate Corporate CLA with the Foundation.

5. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.

6. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.

7. Should You wish to submit work that is not Your original creation, You may submit it to the Foundation separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".

8. You agree to notify the Foundation of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.

Please sign: __________________________________ Date: ________________


12


Provenance

Where did the code come from, original author, primary contributors

Has the license changed?

How did the code come to arrive in the package your investigating?

Resources…

Browser interface to SVN/CVS version control repositories

Dev mailing list archives


13


Keyword scan

Looking for anything ‘interesting’ that suggests code provenance

Copyrights, license, email addresses, “author”, “SCO”…

Need good way to filter out uninteresting keyword hits (“apache” in an ASF project)

Define process for investigating ‘interesting’ hits


14


Records

Assemble Due Diligence package

Keep it in a revision control system


15

LegalGive Credit where credit is due

Acknowledge Creators

In ‘usual place’ (notices or license file, during install, etc)

Documentation


16

LegalThings to make you go “Hummmm…..”

How you package OSS in your product could have legal consequences

Is code segregated or intermingled with your proprietary code?

Go figure…


17

Legal Conclusion

The “Chewbacca” Defense

http://en.wikipedia.org/wiki/Chewbacca_Defense

“If Chewbacca lives on Endor, you must acquit”


18

Agenda


Legal

Community


Final Thoughts


19

CommunityUser or Developer?

Two communities to consider:

User

Developer


20

CommunityModeling of a Community

H U + D * (I / E)

where:

H = Community health

U = # users

D = # developers

I = Developer Intrinsic motivation (end user)

E = Developer Extrinsic motivation (not an end user, ‘professional’ developer?)


21

Community

Reasons for getting involved in the dev community

Influence the direction of the community

Share user experience, communicate requirements

Contribute bug fixes

Innovate

Drive adoption of open standards

Get stuff done


22

CommunityStuff you should know…

Developer Community Volunteers

Fun & recognition

Use OSS in their job

Training & consulting

Academics

“Professional” Open Source Developers


23

CommunityOSS Developer Community 101: Key Concept

Brutal Meritocracy

Open source projects are governed by those with merit

Earn merit by contributing, prove your technical and social cluefullness

Early missteps can compromise your effectiveness in the community


24

CommunityOSS Developer Community 101: Key Concept (cont.)

Brutal Meritocracy

Your corporate affiliation don’t matter

Your schedules don’t matter

You have no rights in the community…

Until you earn those rights, by demonstrating cluefullness.


25

CommunityFirst Step … Lurk, Listen and Learn

Organization Despot, peer or consortium?

Thought leaders

How are releases made, who does the work

Operational Conflict resolution – leader fiat, discussion, bighorn sheep

How to submit patches, bug reports,

Community intrigue – identify frictions in the community


26

CommunityNext Steps…

Research questions before you ask

Start Small don’t come on too strong

Scratch a community itch

Respect developers time

Recognize that everyone has an ego

Thoughtful technical arguments presented well earn respect

Demonstrate Enlightened Self Interest

Maybe you will be invited to become a committer


27

CommunitySpecial Problems of “Professional” OSS development

Companies want to: Define release content

Assign work

Set schedules

Trade innovation for predictability

Reduce intrinsic motivation, stifles innovation

Conservative – reluctant to throw away code, try something new


28

CommunityWhat makes a community successful?

Intrinsic Motivation:

“Your own natural desire to do things well” *

“People work much harder at things they actually want to do” *

Extrinsic Motivation:

Not as strong as intrinsic motivation

Puts food on the table

Can be coercive

Yields somewhat more predictable results

* Joel Spolsky


29

CommunityHow to fail miserably

Short-sited & Self-serving

Ignore discussions not directly related to your interests

Ignore the user community

Don’t do your share of the ‘dirty work’

Be sneaky

Back room decisions

Spring significant amounts of new code on the community with little or no prior discussion

Place corporate agenda ahead of community

Project your problems onto the open source community


30

CommunityReview: Guiding Principles

The Brutal Meritocracy Open source projects are governed by those with merit Earn merit by contributing Participate in the community as an individual, only representing YOURSELF Overtly corporate ‘presence’ unwelcome The most effective communities are brutally effective at enforcing their standards

Don’t be selfish with your time, stay engaged in the community Assist users Fix bugs Stay on top of technical discussions, even if they are not directly relevant to your interests Scratch community itches (don’t be insular and self centered) Demonstrate enlightened self interest

Spend time learning community organization and operational processes Too many to list

Be transparent – no backroom decisions, no surprise codedrops

Respect developer’s time commitments

Readings

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/


31

Agenda


Legal

Community


Final Thoughts


32


Infrastructure

Setup internal source code revision control system

Manage internal development like an open source project

Manage Multiple defect streams

Open Source user/developer community

Internal test team

Your customers


33


General principles

Work defects in the open source community – peer review leverages the collective wisdom of the community

Roll peer-reviewed fixes from the OS community into your service stream

Subscribe to the source code commit mailing list… watch every single patch that goes into the source and assess whether your customers would likely need the fix. Fix problems in your service stream before your customers ever see them

Don’t fork the code base w/o understanding the consequences


34


Security/Integrity defects

This is where being a project committer can be very worthwhile Subscribe to the project’s private mailing list to gain some lead time to fix

problems in your product

Extension Points

Sometimes it is possible to get extension points into the open source code that are generally useful but can be leveraged by you for proprietary extensions (or stuff the community simply is not interested in)


35

Agenda


Legal

Community


Final Thoughts


36

Final Thoughts

Corporate involvement Fact

What (if anything) can an OS community do to ease the friction?

Radical Simplicity Pre corporate OSS communities were severely resource constrained.

Much less likely to do things 'because we can'.

End result was simplest solution to problems

Almost never over-engineered, over optimized

Keep it simple, keep barriers to entry low..

best practices using open source software in commercial products bill stoddard

Documents

legal teamapachecon

legal entity

legal entities

open source software

legal vetting

legal advice

legaldue diligence step

common control