• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
In's and Out's of Open Source Software Policy by Steven Grandchamp
 

In's and Out's of Open Source Software Policy by Steven Grandchamp

on

  • 318 views

Open source expert and former CEO of OpenLogic, Steven Grandchamp, explains the in’s and out’s of open source software policy and governance in this highly visual and easy to understand ...

Open source expert and former CEO of OpenLogic, Steven Grandchamp, explains the in’s and out’s of open source software policy and governance in this highly visual and easy to understand presentation. Companies developing or distributing code will find these slides insightful and beneficial in better understanding why you need a policy and what are the risks of not being diligent in your open source management.

Statistics

Views

Total Views
318
Views on SlideShare
318
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • In the world of compliance, audits seems to be a close cousin. Thank you to the LF for having me.
  • Why are we even talking about this ? Why is it even necessary. From what I see in the market and what we are hearing at OL, Policy becomes a necessary step because software is a leader of innovation for many companies.For those of you that have seen Jim hold up a number of pieces of phone hardware, it’s the software that differentiates them.And in the world of software innovation, there is no bigger driver than open source.
  • As you pursue innovation in your companies, or perhaps even less noble goals such as getting apps on mobile devices, getting your cloud infrastructure off the ground or may getting some traditional applications to SaaS or maybe even trying to make sense of the world of big data.You need to manage the process where innovation takes place. Your goal is to ensure that what you are building, what you are winning with in the market in truly known. That you know exactly what is used in the construction of the application and what that means to your company.
  • And in the world of software today, that is sometimes more difficult than it sounds. Everyone in this room knows all about the choice that oss brings and the many, many doors it can open.But in that world of managing abundance, it can also be a tricky maze to navigate.I will share with you 2 conversations I have regularly with prospects and with customers. 1) CEO – yes, I would love to know what we oss we are using. 2) CTO – we have that under control.Results of an Audit always, always surprise the latter. Never had an audit match expectations.
  • That is why a policy is such a great first step along the road to the most efficient way to use oss. It allows everyone to simply get on the same page.Today, I’ll share with you the 4 In’s and Out’s, our best practices to ensure that you achieve the result you are seeking if you choose to perform an oss audit.First, the Goal – Start with the end in mind if you recall Stephen CoveySecond, distill the common themes of your organization into a set of best practices. We call this a policy. It is the process of getting what people do every day,( distilled into something everyone can talk about using common language. The trick here is that most organizations have different people doing different things. Shining a light on what everyone is doing is the process of policy development.Third, if you boil it down to the single most common element of OSS, especially from a compliance and audit perspective it is the LicenseFinally, no matter your goal, how organized you are and how educated you are on licenses, you will need some overall way to manage it.
  • First, much like any successful endeavor, you need to have a clear goal set in front of you. Why even do this, why perform this audit. Seems like a lot of work.Lets harken back to the conversation between the CEO and the CTO
  • A lot of folks believe they know what they have, what their code contains. What they are looking at.Here is a recent example where lots of folks were sure what this image was .
  • There are many valid reasons to perform an audit. Just know which one you are pursuing. First up is THE LIST. This is the infamous list provided by someone in engineering. Joe is using these oss packages, jim is using a few others. I know we use some libraries that come out at final build. Lets pull together a list of of what we know we are using, lets use the audit to verify this.
  • The exact opposite approach is also valid. We are aware of how fast engineering is moving, how much change is happening. We do not think we have any problems, however we would really like to take deep look at the code base and see exactly what we find.There is an old saying from my Microsoft days from Jim McCarthy, head of the old Visual C++ unit, applied to the smartest people on the team. I am aware of how dumb I am ! I’d really like to find out what I DON”T KNOW.
  • And then the other most common goal is driven by the technology. What are the security standards we need to follow ? Are there EA standards we need to follow ? What about standarizing on certain components. If we know EXACTLY what we have, then we can track things like security patches, new release etc.
  • There are other factors that may influence your decision on Goal. Intent - are we worried about anything or anyone using non standard or non approved ? Do we have a good mgmt process in place. Is the application going to be distributed? How old is the code ? Are the authors still around ? And the most obvious, is this an M&A transaction
  • Remember a series of tests at the doctor don’t mean your healthy. It just means that they found or did not find things in the specific set of tests they ran. Think Blood Test, Urine Test, PSA Test, Colonoscopy etc.
  • Second, there needs to be some rules around the adoption.
  • For some of our customers their policy and the rules are set by outside events such as this FFIEC letter back in 2004. It identified OSS as not having greater or lower risk, just different risk
  • And that is the key to any policy. Understand that it should be driven to accommodate the risk profile of your company
  • Another key is to make sure EVERYONE gets educated on the policy
  • And finally, it needs to be maintained. It cannot be a static document. Just like your car, as you use it, you will need to tune it.
  • With all this talk about compliance sometimes the basic fact of the license gets lost. If you want to be in compliance, you simply must understand the licenses. After all the #1 goal of a compliance effort is to follow the directives laid out in the license. Now there are certainly many licenses and your policy may dictate which ones get special attention in an audit but regardless you need to understand what you have.
  • When I first got involved with OSS this was a very difficult concept for a lot of enterprise purchasing and legal folks to understand. The license is not really a negotiated contract like they were used to with commercial vendors. It’s much more subtle, it’s right there in the code. We all know it’s there because we click that maddening “I agree” button more than we know.This is why it’s critical to track the oss found in an audit back to the license. It’s in the code and we have most likely already agreed to it’s terms. Problem is we typically don’t know exactly what those mean.
  • Keep in mind that recent rulings and case law support the notion that these licenses are in fact legally binding. It’s not necessarily a bad thing, it is just a thing you need to be aware of and it is a critical outcome of any audit.
  • It’s especially challenging if your teams are used to standard licenses as these licenses are most certainly not standard to anyone coming out of the traditional software licensing
  • Another thing to remember is that licenses do changeRecent examples – Apache Commons moved to Apache 2.0 licenseWe are seeing many projects that used to use Sun binary code license move to dual license with GPL Aspect J went from Common Public License to Eclipse Public LIcense
  • Note that many, many OSS uses other OSS. This creates a big issue especially if you are not aware of any embedded requirements
  • For those of you who have not yet started, here is a suggestion from a number of our customers where they got the best impact, the fastest
  • The first thing to focus on in managing oss is to look at your existing process in place for software development and procurement. Piggyback this OSS software request and approvals into that process. It will be slightly different, which I will discuss in just a bit but it can be done
  • Second, know where you can go to get help. There are 3 ways to think about this. First, self helpThen general helpThen custom help
  • Finally understand that you will actively be making decisions around risk management. In some cases you will decide to simply accept risk, in other cases you may decide to avoid it or simply reduce it
  • Another component of your Risk Management Process is remediation. Remediation is deciding what to do with applications that have oss in place BEFORE your policy existed.
  • To Summarize, Follow these guiding principles. Tie to an existing process, perhaps EAUnderstand management is not something different, perhaps automation of your policyKnow where to turn for help and for what kindsStart simple

In's and Out's of Open Source Software Policy by Steven Grandchamp In's and Out's of Open Source Software Policy by Steven Grandchamp Presentation Transcript

  • In’s and Out’s of OSS Policy Steven Grandchamp CEO (former) OpenLogic (Acquired by RogueWave Software Aug 2013) © OpenLogic. All rights reserved. In’s and Out’s
  • What is the Big Deal? © OpenLogic. All rights reserved. In’s and Out’s
  • The End Game © OpenLogic. All rights reserved. In’s and Out’s
  • The Starting Gate © OpenLogic. All rights reserved. In’s and Out’s
  • SCOPE OF FOSS GOVERNANCE FOSS Supplier Contracting FOSS Provisions* IP Review Process FOSS Distribution Process (SW Packaging Process) Outgoing FOSS (FOSS Distribution) FOSS released through Divestiture FOSS Company‟s Customers„ outsourced SW developed by Company Incoming FOSS Contribution Process Contributing Company‟s Proprietary SW as FOSS Projects FOSS Acquisition Review Process* Outgoing FOSS Contribution Process Contributing Fixes and Enhancements to FOSS projects Outgoing FOSS Contribution Incoming FOSS (FOSS Acquisition) Incoming FOSS Contribution FOSS acquired through M&A Outsourced SW 3rd Party Proprietary Development SW (containing (containing FOSS) FOSS) Accepting 3rd Party Contributions to Company Sponsored & Managed FOSS Projects Customer Contracting FOSS Provisions Company / 3rd Party Proprietary SW (containing FOSS) COPYRIGHT © 2013 ALCATEL-LUCENT – ALL RIGHT RESERVED.
  • The In’s and The Outs Goal Policy License Managing © OpenLogic. All rights reserved. In’s and Out’s
  • Goal The Goal Why are you even thinking about having a “Policy” ? © OpenLogic. All rights reserved. In’s and Out’s
  • Goal Recognize This? © OpenLogic. All rights reserved. In’s and Out’s
  • Goal The List? Verify what we think we are doing? © OpenLogic. All rights reserved. In’s and Out’s
  • Goal The Code? Don‟t know what we don‟t know? © OpenLogic. All rights reserved. In’s and Out’s
  • Goal The Technology? Are we concerned about Security or other technology related issues in the code ? © OpenLogic. All rights reserved. In’s and Out’s
  • Goal Other Factors • • • • • • Intent Maturity of Development Process Nature of Application Age of Code Base Availability of Code Author M&A © OpenLogic. All rights reserved. In’s and Out’s
  • Goal What is your Policy Goal? © OpenLogic. All rights reserved. In’s and Out’s
  • Policy Process, Tools and People As lightweight as possible, or no one will follow the policy. Think achieving balance of Risk vs Reward © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • Policy Starting Point © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • Policy Keys to Policy © your company name. All rights reserved. Challenges of OSS in the Enterprise
  • Policy Keys to Policy © your company name. All rights reserved. Challenges of OSS in the Enterprise
  • Policy Keys to Policy © your company name. All rights reserved. Challenges of OSS in the Enterprise
  • License The License It‟s what makes the code Open Source OpenLogic. All rights reserved. In’s and Out’s
  • License It’s actually in the Code © OpenLogic. All rights reserved. In’s and Out’s
  • License Legally Binding © OpenLogic. All rights reserved. In’s and Out’s
  • License Of a Different Flavor © OpenLogic. All rights reserved. In’s and Out’s
  • License Do Licenses Change? They can and do change from version to version © OpenLogic. All rights reserved. In’s and Out’s
  • Be Aware of Embedded Licenses © OpenLogic. All rights reserved. In’s and Out’s License
  • License The Basics • Open Source • Unilateral permission • • • • • • © OpenLogic. All rights reserved. Restrictions on type of use, number of users, redistribution Licensor obligations • • • Specific to parties Grant of rights • No warranty No support or updates implied No licensing fee Negotiated terms • Can copy, modify, distribute May allow other end users to do the same Licensor obligations • • • Anyone can use Grant of rights • • • Traditional Warranties, support, updates Infringement indemnification Typically licensed for a fee In’s and Out’s
  • License Your Mission © OpenLogic. All rights reserved. In’s and Out’s
  • Manage Why Manage? Realize the benefits, Manage the Risk © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • Manage Process Integration © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • Manage Getting Help © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • Risk Acceptance Process © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise Manage
  • Manage Remediation © OpenLogic. All rights reserved. In’s and Out’s
  • Manage Guiding Principles • Tie to an existing business process around use of software; ie: EA process • Management is simply an electronification of policy, not something new • Help – Self support, Generalist Support, Specialty Support. Most companies augment self support • Start simple with Risk Acceptance. High, Medium, Low Risk Ratings © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • Risk Acceptance Principles Manage Management • Rate risk based on OSS component, ie: license or maturity (and) • Application use model, ie: distribution or internal use • Remediation – For those applications found to have OSS prior to policy • Create OSS inventory repository, update and certify accuracy annual or semi annual basis © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • Manage Management Other - SPDX • Working group organized under the Linux Foundation • The Software Package Data Exchange® (SPDX) specification is a standard format for communicating the components, licenses and copyrights associated with a software package. • Reduces redundant work by providing a standard format that can be passed along the supply chain • SPDX License List • a list of commonly found open source software licenses for the purposes of being able to easily and efficiently identify such licenses in an SPDX document. The SPDX License List includes a standardized short identifier, full name, vetted license text, other basic information, and a canonical permanent URL for each license. By providing a short identifier, users can efficiently refer to a license without having to redundantly reproduce the full license. © OpenLogic. All rights reserved. Challenges of OSS in the Enterprise
  • The In’s and The Outs Goal Policy License Manage © OpenLogic. All rights reserved. In’s and Out’s