Upload
leo-lamb
View
217
Download
1
Tags:
Embed Size (px)
Citation preview
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
ApacheCon Europe 2007
3
What is Open Source?
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)
ApacheCon Europe 2007
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?
ApacheCon Europe 2007
5
Agenda
What is Open Source?
Legal
Community
Service Stream Maintenance
Final Thoughts
ApacheCon Europe 2007
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
ApacheCon Europe 2007
7
Legal
Two questions
Q1: Does the license allow you to do what you want?
Q2: Are you certain?
ApacheCon Europe 2007
8
Legal
But what you really need is….
ApacheCon Europe 2007
9
Legal
Due Diligence
Method for investigating source code provenance
Hard work
ApacheCon Europe 2007
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
ApacheCon Europe 2007
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: ________________
ApacheCon Europe 2007
12
LegalDue Diligence Step 2
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
ApacheCon Europe 2007
13
LegalDue Diligence Step 3
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
ApacheCon Europe 2007
14
LegalDue Diligence Step 4
Records
Assemble Due Diligence package
Keep it in a revision control system
ApacheCon Europe 2007
15
LegalGive Credit where credit is due
Acknowledge Creators
In ‘usual place’ (notices or license file, during install, etc)
Documentation
ApacheCon Europe 2007
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…
ApacheCon Europe 2007
17
Legal Conclusion
The “Chewbacca” Defense
http://en.wikipedia.org/wiki/Chewbacca_Defense
“If Chewbacca lives on Endor, you must acquit”
ApacheCon Europe 2007
18
Agenda
What is Open Source?
Legal
Community
Service Stream Maintenance
Final Thoughts
ApacheCon Europe 2007
19
CommunityUser or Developer?
Two communities to consider:
User
Developer
ApacheCon Europe 2007
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?)
ApacheCon Europe 2007
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
ApacheCon Europe 2007
22
CommunityStuff you should know…
Developer Community Volunteers
Fun & recognition
Use OSS in their job
Training & consulting
Academics
“Professional” Open Source Developers
ApacheCon Europe 2007
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
ApacheCon Europe 2007
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.
ApacheCon Europe 2007
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
ApacheCon Europe 2007
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
ApacheCon Europe 2007
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
ApacheCon Europe 2007
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
ApacheCon Europe 2007
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
ApacheCon Europe 2007
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/
ApacheCon Europe 2007
31
Agenda
What is Open Source?
Legal
Community
Service Stream Maintenance
Final Thoughts
ApacheCon Europe 2007
32
Service Stream Maintenance
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
ApacheCon Europe 2007
33
Service Stream Maintenance
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
ApacheCon Europe 2007
34
Service Stream Maintenance
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)
ApacheCon Europe 2007
35
Agenda
What is Open Source?
Legal
Community
Service Stream Maintenance
Final Thoughts
ApacheCon Europe 2007
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..