The policy is published under the Creative Commons Attribution-ShareAlike 2.5 license, so any company can use it, under the terms of the license, as a starting template to create their own FOSS policy, or in the press release's words, to "review, model, and adopt their own." Some attendees at last week's Massachusetts Software Council's SIG Kickoff meeting were asking how companies should interact with the FOSS community, and here is the Optaros answer.

Optaros is a consulting services company that helps businesses use Open Source software, and the company expects, even requires, employees to contribute to FOSS projects, but their policy had to take into consideration the requirements of their clients, too, and on his blog Walli explained a bit about the policy, saying that "as a consulting services company our customers may sometimes require us to do work in ways that we can't simply publish, and we need to keep a foot in both the free and the open source worlds."

As more and more traditional businesses see the value of adopting FOSS, they may find themselves with a foot in both worlds too. And they need to know how to make that work. Having a FOSS policy is, I believe, a pragmatic step, so employees know what it acceptable and what isn't. It is also realistic for companies to recognize that their employees are very likely wanting to contribute to FOSS in their free time and that they may wish to use FOSS code in projects for the company, and while that can be to the company's benefit in the right circumstances, it's also important that employees know the importance of respecting the various FOSS license terms. So having a policy in place, a declared policy on how your business expects employees to interact with the FOSS community, is a sensible move, as it removes any confusion on the part of employees, as well as alleviating any questions about code ownership. Everyone needs to know who owns what and who's allowed to do what, particularly in a mixed environment.

I asked Walli if he'd be willing to explain it a bit for you here at Groklaw, and he agreed, so I'll let him tell you the rest, but I'll finish by saying that I will put a link to the Optaros FOSS Policy in our permanent Contracts collection, so if your company needs to come up with its own FOSS policy down the road, and you wish to find this one to work with, you can find it easily.

*************************************

Optaros Publishes Free and Open Source Software Policy,
by Stephen R. Walli

Wednesday we published the Optaros Free and Open Source Software Policy. This policy defines our expectations on how Optaros employees work with the open source community at large.  We recognize that free and open source software forms the building blocks of the solutions Optaros develops for our clients, so we need to give back. In the words of co-worker Dave Gynn:

• We wanted to have a policy that would be attractive to employees who want to engage with open source projects and communities. We believe that developers who participate in open source projects make better consultants.
• We needed to make it clear to our customers that we understand both the benefits of working with open source and the responsibilities that come with doing work-for-hire. In consulting, the client always comes first and nothing in this policy changes that.
• We wanted to make a commitment to the free and open source software community that we will be a good citizen. Being a good citizen is measured in deeds, not words, but this policy shows the guidelines we expect our employees to follow.

While it reads in slightly heavy-handed legal English, the intent is to present it in terms any enterprise developer or enterprise lawyer can understand. There is a huge amount of intellectual property FUD cycling around the industry since the SCO Group started its legal dispute with IBM.  We wanted to reduce the discussion back to a very simple idea -- as a business you have software assets for which you are responsible and what you choose to do with them for the best overall benefit to your stakeholders will depend upon the business you are in. We  wanted to give people a place to start having better discussions based on business pragmatism rather than fear.

We published the policy under a Creative Commons license. We want people to be able to create their own such policies in this space and re-use the parts of our policy that make sense to them without asking permission.

The one part of the policy that will be discussed a lot I'm sure is the section on our community commitment of time to community projects. Every consultant has "bench" time when they are not working for a client. From the business's point of view it would be great to have everyone billable all the time, but it just never works out. We also can't guarantee in advance that we know how much time a consultant dedicates to working on open source projects. We have taken the approach that when an employee isn't working on a customer project, they will be working on free and open source software projects that interest them. Think of this as our Google 20% project.  We want to set the culture at Optaros early.

I appreciate this policy may not go far enough for some in the community, but I think it's a great start as open source software spreads itself deeper into the enterprise, and I look forward to comments and discussions. 

Optaros Free and Open Source Software Policy

Optaros employees' work involves integrating and assembling software components available from the free and open source software (FOSS) communities, as well as developing software ourselves, to deliver client solutions. Our most important commitment is always to our clients and to the business of Optaros.

1. Software You Develop for Optaros

Consistent with our Employee Nondisclosure, Non-solicitation, and Developments Agreement, all software and documentation that you develop as part of your work for Optaros is owned by Optaros. Optaros may license or transfer your work product to third parties such as our clients and maintainers and users of FOSS projects.

2. Understand FOSS Licenses

All software from FOSS projects should have a license that describes the terms of use of that software. You have an obligation to understand the license terms applicable to any FOSS package you want to use and the implications of those terms on your project at Optaros. This is true for all FOSS projects, regardless of whether you want to use some fragment/component of the FOSS project, or the FOSS project in its entirety. Please confirm your intended use of software from a FOSS project with your project manager or practice leader and the Optaros Open Source Review Board. Use of an already-approved FOSS project with a different Optaros project or customer, or use in a different manner, should be reviewed with your project manager or practice leader and the Optaros Open Source Review Board.

3. Respect FOSS Licenses

Any work you do with software from FOSS projects (e.g. use, changes and additions) is governed by the terms of the license that applies to that software. Optaros, Inc. employees will respect such licenses at all times in their use of the software, and will take the steps necessary to comply with the license terms, including, just as a few examples, the maintenance of copyright notices and other notices, any source code publication and distribution requirements, documentation requirements, and other such terms of use.

4. Contribute back to the Community what is the Community's

You should plan to contribute any development on a FOSS project (e.g., bug fixes, enhancements, modifications) back to the project's sponsors. Contributions you make may not be limited to software, but could include documentation (e.g., reference and how-to), translations, etc. Optaros will work with FOSS project sponsors to follow their procedures for contribution submissions, including assignment of ownership. FOSS projects are under no obligations to accept any changes Optaros employees make, so we should do our best to make contributions that are acceptable to the FOSS projects with whom we work. For example, contributions should always be made following the FOSS project's style and coding guidelines. Our goal is to minimize any forking of FOSS project code, as this is the most engineering-expedient solution for us and our clients, and the FOSS project itself.

5. Optaros-Sponsored FOSS Projects

As we deliver client solutions, we will develop original work at Optaros that may not fit directly into an existing FOSS project, but would otherwise be useful to a broader community. In such cases we may publish the work and license it using an appropriate FOSS license, and work to build a community around it. We may submit it as a subproject of an existing FOSS effort, or it could be a standalone endeavor.

The decision about what software is licensed into such Optaros-sponsored communities will be made by the Optaros Open Source Review Board in cooperation with the developers.

6. Optaros Employee Community Commitment

Every consultant has “bench” time when they are not working on a customer solution. Free and open source software forms the building blocks of our solutions for our clients. The more familiar you are with particular FOSS projects and tool sets, the better we can deliver solutions to our customers within our practices. To that end, it is expected you will spend at least 10% (but no more than 20%) of your work at Optaros directly participating in relevant FOSS communities. These relevant projects could be outside projects or Optaros-sponsored FOSS projects.

This is different from the time you may spend on FOSS project software within the context of a specific client engagement, e.g., bug fixing, extending and modifying the work to develop a client solution. Thus, your FOSS community commitment is separate from customer billable time.

7. Original Software You Already Own

You identified the software you owned before you joined Optaros in your Employee Developments Agreement. You are obviously free to choose how you license such software and it is your responsibility. Any such software that you privately hold, i.e., that which is not licensed under a FOSS license, must be cleared with a company executive before it is used in work relating to Optaros, Inc.

8. Extracurricular Work

Developing software for hire outside of Optaros needs to be cleared with the CEO or their designee. Developing your own software projects that you privately hold on your time and equipment needs to be cleared with your manager in the context of your obligations to assign the software you develop to Optaros and the subject matter of the project you want to work on. Developing your own new software projects on your own time and equipment that is licensed as FOSS is likely to be acceptable, but please confirm this work with the Optaros Open Source Review Board. Likewise, participating in an existing FOSS community on your own time and equipment is likely to be acceptable, but we ask that you confirm the work with the Optaros Open Source Review Board.