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:43:40 GMT
On Tue, Mar 22, 2011 at 6:11 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> 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.

Your suggestions are very permission-based rather than defining
standard procedure that can be audited after the fact. 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.

> 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.

Agreed; but throw the managers out imo. Also ensure that you don't
bake in the idea that permission must be asked, a liberal policy would
optimize 99% and restrict 1%. A conservative policy would be the
opposite.

> 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.

That's still pretty conservative :) You're allowing a single
conservative use case to continue to exist on on-going probation. It's
a very minor optimization.

>> >> - 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?

On those subjects - a basic understanding. The important items are:

* 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'.
* Recognizing an internal product (pretty easy), and seeing a list of
frowny licenses. Generally easy. The main complications will occur if
the company are heavily involved in patents; in which case I suspect
they'll be after a more conservative policy.

> 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.

Good luck :)

The internet is large and the overlap with social is complete. My
linkedin is 5 seconds away from my rant on facebook, and 3 seconds
away from my real time re-enactment of the battle of agincourt on
twitter. People's understanding of licensing would be my least worry -
the ability to be civil and polite, especially in the face of an
aggressive committer.

> 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.

Not very liberal again :) Plus pulling in a less clueful supervisor.
I'm not arguing that there shouldn't be options; but an
approval-by-management structure isn't going to work (see below).

> 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.

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. 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.

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.

One item that the process needs to cover is recording the
contributions a company have made.

>> 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...")

Yup :)

> 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. One that gives
structure but doesn't mean hiring people to manage or limiting the
drive of the employees. Those who want to be more conservative can
start from there and work rightwards.

>> 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.

Yup. I've listed the policy items that process is built around; Ross
has the introduction/vision for the policy.

> 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.

Lists help there. Also making no reference to existing employee
structures (supervisors etc). Should be doable.

Hen

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


Mime
View raw message