Bring Order to Your Open Source - page 2
Building an Open Source Policy
Fan doesn't expect any organization to achieve 100% compliance, but they increase their chances if they start by understanding what type of a culture they have--freewheeling where engineers have a lot of autonomy, or very buttoned-up with policies strictly enforced.
"Then craft a policy that gets that culture to maximum compliance," and don't stop there--consider yearly audits and training so that you are always educating and advising IT members on the topic.
What is key to a policy?
For Great American, "we're worried a little bit more about making sure that we're using the right open source projects, that we have the appropriate amount of support from them, and that we've mitigated risks from a usage standpoint," says Bunch.
Key is avoiding problems with open source license agreements by avoiding having developers get in and customize or support open source.
"Our policy is that we are dealing with known versions and distributions of open source projects, so we have the ability to support those for our enterprise applications that we're doing development with."
So-called reciprocal licenses can be a concern for clients, says Fan, and most of the policies Olliant writes have very specific provisions for dealing with these types of licenses, with a focus on distribution. "It's the redistribution that tends to trigger the clause that requires you to open source your own code," he says.
How can you speed up approvals for open source projects
White lists of pre-approved open source can be one way of doing it. Publish examples and lists of specific open source packages and versions that are pre-approved on a web page or Wiki, as well as pre-approved license types, will over time reduce overhead, confusion and redundancy, for both policy groups and developers, says Fan.
Great American ascribes to that, with a white list of supported open source projects that primarily focus on mainstream and mature open source projects. It's very careful about maintaining development standards to avoid, for instance, multiple development frameworks for user interfaces.
But Robb offers one note of caution about pre-approved lists, noting that is particular not just about the open source used but about the context in which the software is used. Instead, it has a fast track process in place where program managers, vs. the policy group, can give the go-ahead if there's a clear understanding of the components, how they will be used together, licenses and context. In one way or another, "we always try to look at context before we say yes."
The experts presented their advice this week during a webinar entitled Open Source Governance and Policies in Enterprise Organizations, sponsored by OpenLogic, which provides software and services for open source management.
This article originally appeared on bITa Planet, a JupiterWeb site.
- 1Linux Top 3: Fedora 24, Peppermint 7 and Solus 1.2
- 2Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 3Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 4Linux 4.6 Charred Weasel adds USB 3.1 Support
- 5Linux Top 3: OpenIndiana 2016.04, Ubuntu 16.04 and Debian's New Leader