decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Optaros Publishes FOSS Policy
Friday, July 01 2005 @ 08:24 AM EDT

Now this is interesting. Stephen R. Walli, Vice-president, Open Source Development Strategy, at Optaros, Inc. brought to my attention the new Optaros Free and Open Source Software Policy, which spells out exactly how Optaros would like its employees to interact with the FOSS community and what is and isn't appropriate. Here's the press release.

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.


  


Optaros Publishes FOSS Policy | 56 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Off topic here please
Authored by: fudisbad on Friday, July 01 2005 @ 08:33 AM EDT
For current events, legal filings, 3rd amended complaints and Caldera®
collapses.

Please make links clickable.
Example: <a href="http://example.com">Click here</a>

---
See my bio for copyright details re: this post.
Darl McBride, show your evidence!

[ Reply to This | # ]

Corrections here please
Authored by: fudisbad on Friday, July 01 2005 @ 08:34 AM EDT
If required.

---
See my bio for copyright details re: this post.
Darl McBride, show your evidence!

[ Reply to This | # ]

I dig
Authored by: Matt C on Friday, July 01 2005 @ 08:59 AM EDT
Where do I send my resume?

[ Reply to This | # ]

  • I dig - Authored by: Anonymous on Friday, July 01 2005 @ 09:30 AM EDT
    • Got it - Authored by: Matt C on Friday, July 01 2005 @ 09:37 AM EDT
      • Got it - Authored by: Anonymous on Friday, July 01 2005 @ 03:55 PM EDT
Optaros Publishes FOSS Policy
Authored by: algorythm on Friday, July 01 2005 @ 09:54 AM EDT

I'm curious to see what kind of contract a client of Optaros signs. It seems to me that there must be some kind of "By the way, we may include any specific tweaks, documentation, etc. we do here back to the original FOSS project" clause. If there is, it'd be interesting to see how that bit is worded. Also, I wonder if such a clause makes some folks 'nervous' and how the company addresses those concerns.

However, the policy itself look about right to me, and is a much needed resource to the community imo. I've been trying to find examples of such a document for the past couple months (being in the middle of trying to clarify my employers views on FOSS stuff I write in light of the "we own everything you do on or off the clock, for up to one year after you leave" IP clause I signed when hired).

I could really only came up with one, the OSDA courtesy of SAGE-AU.

Kudos to Optaros for 'getting it'.

[ Reply to This | # ]

Optaros Publishes FOSS Policy
Authored by: rdc3 on Friday, July 01 2005 @ 10:19 AM EDT

Very interesting. This appears to be an excellent way for a FOSS-oriented company to lay out its expectations to employees.

One caveat, though, is that Optaros itself does not appear to be binding itself to take any particular actions. Employees must plan for their work to be contributed to appropriate FOSS projects, but Optaros "may" or may not. It might be nice to see a term that would at least allow employees to insist on some accountability process for the contributions they make, i.e., if they planned for some work to be a FOSS contribution, but Optaros did not make that contribution, the employee should be entitled to some review process.

[ Reply to This | # ]

Areas where clarification/further work would be helpful
Authored by: marbux on Friday, July 01 2005 @ 11:21 AM EDT
I had a few thoughts after reading this excellent beginning. For the most part, my observations stem from not knowing the actual procedures established in your organization to implement the policy, other than what is stated in the policy itself. So take these suggestions with a grain of salt.

  1. Make the policy a living document. Few new policies last long before they are either amended, interpreted, or ignored. Establishing a participatory and easy-to-use process for incorporating suggested changes/elaborations can be invaluable. Creating a record of such amendments would likely be endorsed by your legal counsel. To meet such needs, you might consider establishing an internal CVS-based wiki with hierarchical editing permissions corresponding to relevant levels of supervisory and implementation responsibility.

    Should you pursue the wiki suggestion, you might consider a lawyer's technique for organizing the "living document." Some lawyers begin with a copy of the complaint in a given case and break it up in a word processing file with one sentence per page followed by notes or a table collecting case file references to the relevant evidence, supporting legal memoranda, etc. This provides a quick and dirty method of organizing evidence and other information needed at trial that is highly focused on the allegations of the complaint. For lawyers, that helps to prevent discovering at trial that crucial evidence has not been developed.

    Likewise, each individual sentence of your organization's open source policy might link to a wiki page for it and for collecting and linking that sentence's amendments, refinements, and related matters. When a needed refinement does not fit logically under a top-level sentence, it is time to amend the original policy accordingly (or to amend your complaint; YMMV).

  2. Create an organizational history of code sources and resources. Likewise, creating a history of the actual history of code sources (both open source and proprietary) would also be invaluable, for purposes of legal defense and to identify people within the organization who have relevant expertise and other coding resources. Project-level histories might also be incorporated into the wiki suggested above. With wiki software's easy hyperlinking, it should become trivial over time to review the organization's historical use of code from given external sources and to discover who was involved.

  3. Establish a simple method for suggesting changes and additions. Inevitably, initial written policies can not foresee every situation and ambiguity that may arise. This will translate either into unwritten refining policies at lower supervisory levels or into a process for more formally amending the policy so that all concerned can benefit. You may wish that the policy reflect actual practice rather than aspirational goals. Therefore, a transparent system for accepting suggested changes and tracking their processing may be desirable. Again, a CVS-based wiki might offer a simple solution, although at the other extreme a more formal work order system (e.g., a "feature request" tracking system) might be implemented. However it is implemented, the process should be simple to initiate and should be encouraged.

  4. Recycle lessons learned. Considerations and resolution of unforeseen situations should be documented and easily accessible so that the organization can avoid reinventing the wheel when further unforeseen situations arise. Lessons learned can range from simple file notes to formal legal opinions of counsel. Again, a wiki's easy hyperlinking can offer an easy method of organizing and recycling such information.

  5. Establish accountability for implementation. I hesitate to suggest establishing a formal reporting requirement. Bureaucracy is a burden in any setting. However, you might consider lesser incentives for implementation, such as using spot checks or instructing (and letting it be known) that open source policy compliance will be a mandatory consideration in periodic staff evaluations. You undoubtedly have your own preferred methods of ensuring that policies are implemented, but that consideration seems to be missing from the open source policy statement. But again, use of a wiki would dramatically reduce the burden of such reviews.

  6. Consider incentive awards. In an organization of motivated people, the carrot usually is a far more effective management tool than the stick. Consider opportunities for publicized incentive awards for suggestions and innovation in implementing the policy.

Obviously, I am beating on the wiki drum loudly. But with any new policy, the real work is in the implementation. The wiki method of implementing projects has a proven track record, producing a useful marriage of information and meta-information. I suspect a wikified approach would be useful in this context.

---
Retired lawyer

[ Reply to This | # ]

Somebody gets it
Authored by: RealProgrammer on Friday, July 01 2005 @ 11:36 AM EDT
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.

To amplify on that a bit: one of the selling points of FOSS to a typical client company (over writing their own, or keeping the fork a secret) is that they don't have to find all the bugs. By turning their changes back over to the main project, their fixes stay in the main project while everyone's bug fixes are applied.

With a project fork, you have to watch both branches to make sure that the bugs are fixed.

A hidden advantage is that of Optaros implements a solution for a client, if the solution is part of an open project it doesn't matter to the client so much if Optaros goes out of business. Someone else can step in. Obviously companies like to maintain comfortable partnerships, so there's not really an added threat to Optaros that the client will go to some other consultant.

---
(I'm not a lawyer, but I know right from wrong)

[ Reply to This | # ]

One part I disagree with
Authored by: cmc on Friday, July 01 2005 @ 01:53 PM EDT
Not really being part of the FOSS community myself (I don't yet have the
expertise to contribute), I'm certain that I don't understand the big picture.
Having said that, this does seem like a very good thing. It's refreshing to see
a company that wants to support the community that the company is (at least
partially) built upon.

The one part I disagree with, and I have a feeling many developer jobs are like
this, is that you need permission for any off-the-clock projects or community
involvement. That doesn't go so far as (for example) IBM, who we have been told
requires all of your off-the-clock projects assigned to them, but it's certainly
a negative aspect (in my mind, at least). By and large, programming is a way of
life, not a job, and you don't just turn it off when you leave work. I
understand the importance of keeping work and personal projects separate, and
the IP issues that can go along with it, etc, but asking for permission to start
a separate project would make me feel like a child. I don't know, maybe I'm
off-base, but that's how I would feel.

cmc

[ Reply to This | # ]

Optaros Publishes FOSS Policy
Authored by: Anonymous on Monday, July 04 2005 @ 08:36 AM EDT
So, this U.S. company appears to "get it". Does anyone know of any
companies in the U.K. that have a similar understanding and appreciation of
FOSS?

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )