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