www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <he...@yandell.org>
Subject Re: Liberal corporate open source policies
Date Wed, 23 Mar 2011 04:07:40 GMT
On Tue, Mar 22, 2011 at 5:24 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> Hello, Henri,
> Thanks for the thoughtful response.  I'm dividing my reply across two emails;
> this one to cover what kind of product might emerge from this discussion and
> where it might live, and the other to cover content.
> On Mon, Mar 21, 2011 at 01:01:24AM -0700, Henri Yandell wrote:
>> 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@).
> At some point, I'd like to see this sample open source policy published on an
> ASF website.  I can think of three potential homes for it: legal affairs, dev,
> and community.
> It seems plausible that legal affairs might be consulted at some point, but I
> think this policy is distinct from its mission.  Legal affairs is concerned
> with activities that involve the ASF and IP licensed to the ASF directly.  The
> adoption of this sample policy would govern the relationship between a company
> and its employees; the ASF would not be involved.  It's akin to projects
> outside the ASF using the Apache License or our CLAs...
>    http://www.apache.org/foundation/licence-FAQ.html#My-License
>    http://www.apache.org/foundation/licence-FAQ.html#CLA-Usage
> ... except that the ASF would never actually use this document.  Legal affairs
> expertise is a limited resource, and if we don't have skin in the game, I'm
> hesitant to suggest that it live there.

I'll challenge that one. The ASF employ individuals to develop, and
they contribute back as a part of their job. If you're looking for a
liberal policy, I suspect documenting the policy at the ASF would be
pretty damn liberal :)

So potential goal there - your liberal policy would have to stretch to
the extremes of the ASF and other foundation employers.

> For similar reasons, www.apache.org/dev might not be ideal.  The dev site is
> aimed at individual developers contributing to the ASF and engaging in ASF
> governance activities.  The target audience for this document would be IT
> management.  It might be brought to the attention of management by developers
> who want to contribute to the ASF, but the there's a huge amount of material
> on the dev site that wouldn't be relevant for the people we'd want to reach.
> I've looked around the community.apache.org website, and while there is not an
> obvious home for it there, it's an interesting question whether a place could
> be carved out for it.   Trawling through email archives, past board reports,
> and blog entries, I see that coordinating Google Summer of Code has been a
> major focus, and that questions have been asked like "How might we attract
> more technical writers to the ASF?".  This seems like a similar outreach
> activity, intended to bring more people to the ASF and make it easier for them
> to contribute.

The primary value would be in decreasing the time it takes for a
company to go from user to contributor to committer-employer,
incubator-source and/or sponsor.

> Perhaps if we can craft a document of suitable quality, the Community PMC
> could be persuaded to assume responsibility for publishing it and voting to
> "release" it once it becomes mature enough.  Call it the "Apache Community
> Open Source Policy 0.1"?

I'd challenge the statement

>> Find a wiki and start documenting. :)
> I'm inclined to compile a draft/outline and open a JIRA issue.  There has been
> enough material in this thread to get started.

Charge along :)

> I don't think the policy itself should be developed on a wiki because we'd
> potentially get contributions from people without CLAs on file, and I'd like
> the ASF to have full freedom to use the material that comes out this process.
> (I'm sure you of all people grok the licensing limitations of wiki documents,
> though, so I've probably misunderstood your suggestion.)

More that I'm less concerned by having CLAs on file to peer-write a
document than I am to writing code. :) If someone ends up writing some
huge part without a CLA, it's auditable and we can ask them to sign

The value a wiki has for document development far blows away the pain
of asking one person to sign a CLA. Doing this in a JIRA would be less
likely to succeed imo; there's no existing lure to contribute so it'll
be harder to get involvement than a patch would.


To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message