On Tue, Mar 22, 2011 at 09:43:40PM -0700, Henri Yandell wrote:
> > 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.
>
> Your suggestions are very permission-based rather than defining
> standard procedure that can be audited after the fact.
True. I'm struggling to understand the full implications of blacklisting vs.
whitelisting.
To what extent does a permissive blacklisting strategy put the organization at
increased risk for a misguided or inexperienced employee open-sourcing IP that
should have remained proprietary? To what extent does management have a
fiduciary duty to exercise oversight and prevent such damage to the company?
How does management demonstrate that they have discharged their
responsibilities?
I suspect that in practice, these objections are overblown -- managers and
employees working together in today's world under a variety of IP regimes do a
good job of not leaking valuable proprietary material through employee
interaction with open source. Nevertheless, I am certain such questions will
be asked -- since people have already asked me about them.
We should ask hard questions now, and ideally craft the language of the policy
itself to assuage such concerns -- or at least not needlessly exacerbate them.
(Expansive answers probably belong in a complementary FAQ.)
> I'd also be hesitant to suggest supervisors are a good permission delegation
> structure. They're probably less educated than the individual looking to
> contribute.
Sure, I imagine that's true on average. However, the permissions regime is
not so much meant to avoid licensing problems as it is to allow management to
make strategic decisions as to what should be open-sourced and what should
remain proprietary.
My sense is that it's almost always beneficial for the individual employee if
their IP gets open-sourced. Said individual gains an enhanced reputation
within the open source world as a contributor and potentially as an expert
within their domain; additionally, open source code can be more fun to work
on because fewer compromises need be made to accommodate scheduling and
budget constraints. For the organization, though, the calculation is more
complicated. Does the IP confer a competitive advantage if held closed? Open
source code often has to be higher quality, clearly-laid-out and accompanied
by proper documentation and tests; does the burden of conditioning the IP so
that it will be meet the standards of an open source project increase
development costs? What are the maintenance costs if valuable patch X is kept
proprietary and must be continually updated and applied to new releases? How
about project Y, if that gets open sourced by us, how much time are the
authors (our employees) going to spend on support, and how much will the
community give back? And so on...
Where tension exists between the interests of the company and the interests of
the individual employee, it seems natural for management to exercise
some degree of oversight.
> * Recognizing a distributed product. At a small company this is easy
> to define. They can then have a list of happy, need-help and frowny
> licenses. Also a small treatise on 'how to attribute'.
Do you envision embedding such a passage on attribution within the Policy
itself?
Seems like a "nice to have", but not a requirement.
> Whether to blacklist or whitelist is a core decision and even for a
> liberal policy blacklisting has the risk of how long it takes to get
> something on the blacklist and the cost of something being contributed
> to the blacklist.
OK, I'm starting to grasp how this might work. It's analogous to your
suggestion of using the wiki to develop the Policy's language rather than
JIRA: audit after the fact to make sure that everything's kosher. "It's
easier to beg forgiveness than to ask permission."
With a small team of experienced people, the risk would be negligible. (No
policy would ever be zero-risk.) When you expand the team outwards to include
people with minimal open source expertise, the risk seems as though it ought
to rise -- but then, such people are less likely to contribute to open source
in the first place, and if they are just starting out, their first steps are
likely to be tentative and uncertain.
I think we can limit the organization's exposure to harm with a rule like
this:
* Employees are only allowed to contribute IP they wrote themselves.
Collaborative works must go through the Open Source Clearance Procedure.
Hopefully, that suffices to protect the organization against blundering by an
inexperienced employee. I don't think it will constrain legit open source
participation too much, since individual contributors generally represent that
contributions are their own work.
There is still the possibility that an employee might open-source a valuable
project of which they are the sole author when the org would have preferred
that it remain proprietary. But that risk is mitigated by an earlier rule
that I proposed:
> > * 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.
We might need to tweak that a bit, but the essence remains the same: give the
employee enough info that they don't get themselves into trouble.
> From that point optimization can be extreme or
> negligible. It's could be considered sensible to go with whitelisting.
> That is, to change:
>
> * List of projects (or type of project) to avoid for specified reason.
>
> to
>
> * List of projects (or type of project) approved for contribution;
> along with any approval process.
>
> That allows a policy to organically build a list of projects that are fine;
> and once they're fine they can open the doors wide open. That's still an
> expensive process - the upper bound means doing business (senior management)
> and IP review (1 or more lawyer) on every Open Source project in existence.
> Bearing in mind that many companies won't have a lawyer on staff, it'll
> roadblock the entire thing.
Yes, I'm concerned about the time it takes to get a project onto the
whitelist. Even if front-line managers are empowered to whitelist open source
projects, they may not feel comfortable doing so. It's easy to get stuck.
For what it's worth, it's just as hard to review an Open Source project for
blacklisting as for whitelisting -- so the upper bound is the same -- but of
course blacklisting doesn't block contributions while the reviews are in
progress or stalled.
> I still prefer black-listing. It carries risk, but it drives the right
> behaviour. A small company should know about the Open Source projects
> that either compete with it, or overlap with their patents. Not
> knowing is just poor business. As they grow, moving to white-listing
> may be necessary, but that can be done by analyzing all contributions
> to date and generating that first white list.
Well, it would be great if even a sizeable company could continue using this
Policy and not feel compelled to modify it.
> One item that the process needs to cover is recording the
> contributions a company have made.
Is keeping an internal record feasible? Requiring that all patch files be
dual contributed to both the open source project and a seperate internal
version control system seems cumbersome. But if you're not willing to go that
far, you have to rely on record keeping by the external open source projects.
Instead, I can see the org keeping a list of the projects that have been
contributed to. Is that what you meant?
> > 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.
>
> It's how I interpreted your 'liberal' wording. What's the most
> liberal, yet still defined, policy that could exist.
A "liberal" policy, to my mind, is one that makes explicit provisions for
relying on the judgment of frontline employees in assessing what IP is
appropriate for open-sourcing on a contribution-by-contribution basis. I had
originally been concerned only with empowering "approved" employees, but I
agree that it would be better if we can empower everyone and remove the
inefficiency of the approval process.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org
