On Mon, Mar 21, 2011 at 01:01:24AM -0700, Henri Yandell wrote:
> > 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. "
It should be possible to accommodate a wide range of project clearance
procedures using shared language. Something like this:
* Permission must be obtained from a supervisor prior to contributing
company IP to an open source project.
* Permission may be granted for an employee to contribute to
individual open source projects on an ongoing basis.
* Employees who have received authorization for ongoing contributions must
consult a supervisor when there is uncertainty as to whether IP should
remain proprietary or be open sourced.
What it takes to obtain said permission might vary widely across different
organizations: managers might be empowered to grant permission directly, they
might be required to engage the legal department on every single call, or
anything in between.
Where I think this "liberal" policy differs from more "conservative" policies
is that it formally declares a procedure for ongoing permission to be granted
where the individual developer is to be entrusted not to leak proprietary
information.
> >> - 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.
That's an admirably concise description of the requirements, but it still
seems to me that the knowledge a dev needs to understand and uphold those
requirements is pretty substantial. How well do they need to grok copyleft,
the FSF's position on derivative works, the Affero GPL, 3-clause vs. 4-clause
BSD, etc? The internet is forever; they are representing the organization in
an archived public venue. They had better know their stuff and take their
responsibilities seriously.
Nevertheless, the policy can be crafted to accommodate wildly divergent
opinions on the subject.
The policy should stipulate that all patches must be cleared by a direct
supervisor unless the employee has been authorized to make ongoing
contributions to a project. I mentioned above that different companies might
have different procedures for granting permission; they might also have
different *criteria* for qualifying an individual.
Deny-by-default for patches seems like the only sensible rule; I doubt it will
meaningfully obstruct ordinary usage of OSS, since as Upayavira asserted
elsewhere in the thread, those inclined to give back will be the exception
rather than the rule. Incidental contributions will inevitably slip through
the cracks on user mailing lists and bug trackers, but that's just part of
allowing your staff enough freedom to be productive users of OSS.
> 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).
(I suspect that should have read "Non-profit orgs...")
I hope that we don't have to craft a custom policy to accommodate the most
lenient orgs. Perhaps they can just be more loose in their administration of
the 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.
Interesting. I was imagining a boilerplate document containing statements
similar to what Ross put in his email. I hadn't thought of filling in the
blanks like that -- but on close inspection, I don't see any
incompatibilities.
I'm not sure if it's a misguided priority or not, but to me it seems important
that if an organization states, "We've adopted the Apache Community Open
Source Policy version 1.0", that means something distinct -- allowing both
current and potential employees to know where they stand.
To that end, I hope that different orgs don't find it necessary to modify the
policy to meet their needs, and I hope that we can craft something suitably
flexible so they don't have to.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org
