On Thu, Mar 17, 2011 at 6:44 PM, Marvin Humphrey mar...@rectangular.com wrote:
On Thu, Mar 17, 2011 at 09:22:57PM +, Ross Gardler wrote:
This is an interesting question. I was recently asked to help with
exactly this issue and I also struggled.
Perhaps we might consider working up an example policy ourselves?
Cool idea :)
It is in the interest of the ASF to make it as easy as possible for companies
to contribute to our projects. Creating a company open source policy has a
cost. If we provide a template policy that is rock solid with regards to
using and contributing to ASF projects at the least -- and hopefully open
source at large -- we can bring that cost down.
In addition, if a company adopts the sample policy verbatim, it becomes easier
for a candidate to assess whether they would be happy there.
I can see a web startup with a limited budget taking the easy route and
adopting an ASF-crafted open source policy verbatim.
I don't know, though -- I'm just an ASF committer on an Incubator project, so
I don't know whether any part of the ASF, if any, would take on such a project
or in what form.
It's a meritocracy; by stepping up with this email you've already
started the project. Stay quietly persistent and keep it going (and I
don't see why it can't stay on community@). Find a wiki and start
documenting. :)
Here's what I told the company that asked me about this:
A healthy policy would look like the outline you describe, some (off the
top of my head) statements that would be appropriate are:
Presumably this outline described procedures for obtaining clearance from
management to work on open source projects?
Depends how liberal you're talking. A liberal company would be more
along the lines of:
Let us know projects you work on. If anything terrifies us we'll let
you know to back out and will add it to the 'please don't' list.
- we will honour all trademarks policies and licences relating to the
projects
This is more challenging than it sounds! The participating employees have to
recieve sufficient training and guidance to execute the policy cleanly.
If we assume the likely user of a liberal set of policies would be a
startup, the main concern is in making sure no copyleft code ends up
in a distributed product, and no network-copyleft code ends up
'networked' in.
Startups tend to get strong advice to secure a few patents. Assuming
they're taking that particular VC advice, then making sure staff know
about the patents they have is very worthwhile and those areas can be
forbidden for open source activities.
That's a pretty small amount of required training. Draw a few
architectural circles to pay more attention in, a few licenses to pay
more attention to and discuss your patents internally such that
employees know to avoid the space.
Other small companies who aren't looking for a sale can afford to be
more liberal. Non-project orgs for example (who I suspect would love
such a liberal policy).
So, here's my liberal, yet not non-existent, Open Source policy:
* List of company products which require someone sign off on
inclusion of Open Source unless under these licenses list permissive
licenses.
* List of licenses which require someone sign off on use anywhere: list.
* List of company patents.
* List of projects (or type of project) to avoid for specified reason.
* Company email address to mail when contributing to a project (having
checked above project-avoid list).
* Company email address to mail to get CCLAs signed.
Hen
-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org
