www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Committers' hobby projects
Date Tue, 28 Feb 2012 07:46:26 GMT
On Tue, Feb 28, 2012 at 5:13 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Feb 27, 2012, at 5:33 PM, Greg Stein wrote:
> > This is covered by our "short form" IP clearance in the Incubator:
> >  http://incubator.apache.org/ip-clearance/index.html
> >
> > Roy said a person can just "check it in" (ie. option A), but I don't
> > think that is really true.
> Yes, it is true.  This question has been asked and answered before.
> > Recognize that the software has been
> > developed outside of our community engagement. Suddenly turning this
> > large piece of code into "Apache code" is generally considered
> > improper. We don't normally let people develop entire products
> > *outside* of the ASF community process, then dump it into source
> > control, and then call it ASF code.
> Sure we do.  See Shambhala.  As long as all of the contributors have
> a CLA on file and all the contributors agree to the contribution,
> then it is covered under those CLAs.  All paperwork complete.
> It doesn't matter where the code was stored in the past.
> > The short-form clearance is intended to ensure that the PMC
> > recognizes, as a whole, what is arriving in its repository. That each
> > of the people who have committed to that code (whether one, or
> > several) have the proper ICLAs on file. etc.
> >
> > If you're talking about 100 lines of code, then what the heck... just
> > commit it. But if you're talking about a subproject that is moving
> > into Commons, then please use the short-form clearance.
> >
> > Cheers,
> > -g
> >
> > ps. the "short form" looks a lot longer than I remember it to be; that
> > process should be streamlined, which is something to discuss on
> > general@incubator
> http://markmail.org/message/zkzsung623jtfa7x
IMHO simply referencing an example of one case to serve as the basis of all
cases is not right here. When trying to level a picture relative to the
floor, you might wind up surprised that the floor was never level either

Below I presume a single committer (with ICLA on file) is importing their
own code from an external repository into an ASF TLP repository area, and
cover the topics of:

   1. Contribution Size (when size matters ;))
   2. Where is the commit being made?
   3. How is it handled?

Contribution Size (when size matters ;))

If this is a simple matter of importing some code from repository to
repository then size does matter since it impacts the community that will
maintain it and work with it. When small, it's not much more than an
average sized single commit, done in phases elsewhere. This is sort of like
the DVCS model (work flow) of development. Someone can follow the commit
and easily understand what's taking place in this case. It makes no
difference if this code is stored locally on your local repository or
stored remotely on some external repository hosting service.

Where is the commit being made?

The question of WHERE the code is imported into a TLP's repository is
important too. If it's in the committer's personal sandbox then the
community inherently understands what's taking place as well as the
committers intentions. A conscientious member of the community usually will
post a descriptive email about what they just did to notify the community.
Often this scenario makes the size aspect less relavent, but of course the
code is the work of the sole ICLA holding community member. So size does
not matter so much; it's all about the motion in the ocean baby.

If this code is dumped as a new sub-project of the TLP, say at a peer level
to those that go through the standard review, vote, then release process of
TLPs, then I don't think this is a proper action. What this translates to
in terms of legalities is what's hazy and I think that's what we're trying
to hone in on in this discussion. Creating a new releasable product at the
ASF requires procedures and some minimal criteria.This is how we safeguard
ourselves legally, our marks, and how we generally try to achieve some
level of project continuity through a healthy community around that code

In the past we've dealt with slicksters who tried to dump code as a peer to
other TLP sub-projects (as releasable products) attempting to sneak in
their work to go straight into the standard review, vote, then release
process. We found this one guy doing this to impress an employer: "Look I
just willed and created this new Apache product all by myself: see what I
can do!" Because the review, vote, then release process was something we
trusted he snuck a few past us. Then a year later we looked and we found we
had a few really crappy code bases without anyone in the community to
support them. Then when this guy was called upon to do something about it,
he went MIA on us. In the end, this strained the community, caused code and
project continuity issues and resulted in a lot of user dissatisfaction. In
the end, we the TLP wound up banding together to cover and support what
this poser did but it was painful. I sure don't want to see this ever
happen again. It undermined the continuity aspect that the incubator

But the point of this past experience is there's a reason why the incubator
requires a disparte group of at a minimum 3 developers on a project. To
some degree dumping a large chunk of code as if it were a candidate for the
simple 72 hour review, vote, then release process is not proper. There's
just no clear way to handle this but through the proper CULTURE in the TLP!

Even a committer with ICLA on file does not have the right to create a new
project on his/her own and mainstream it as a candidate that can go through
the standard review, vote, and release procedure. It might be debatable if
a TLP PMC has this right but that's another question: FYI I think it does
by a narrow margine for various reasons. But it is risky if the TLP is not
healthy. It can over look many things like we did and we were relatively
heathy. This in turn can harm the ASF.  Forget about the code not being
supportable in terms of continuity and community around the code, what
about clearing the marks for the new product? Is the TLP doing this as well
as the incubator does it?

In the end I don't have all the answers for this corner case. But I do
suggest one thing:

The ASF needs to formalize a simple process of product creating (under a
TLP) that requires an ACK from the board. The ACK request should contain
the list of active committers on the subproject as well as the legal name
of the product. All PMC can have their own way to determine candidacy: via
discussion or formal vote. But in the end they need to get the approval for
it from the board. This makes sure a candidate sub-project meets certain
criteria to be made into a releasable ASF product. which goes through the
standard review, vote, release process thereafter.

If this ACK procedure to add/remove new products were mandated along side
the ACK required to add/remove a new PMC members, then I think I would be
very comfortable with Roy's KISS approach as the general rule.

Best Regards,
-- Alex

View raw message