Licensing Issues (was: Re: Board Report due within the half of January)

[David E Jones <jo...@undersunconsulting.com>]

On Jan 7, 2007, at 11:18 AM, Chris Howe wrote:

>
> --- Anil Patel <to...@gmail.com> wrote:
>
>> Chris,
>> How is the work done at the developer's conference
>> is different then work
>> done at my Home. As long as I create a Jira Issue
>> and submit a patch there.
>> The advantage will be I'll have commiter accros the
>> table who can get it
>> from Jira and review and apply the patch.
>>
>> Anil Patel
>
> If you're the only worker on the the contribution,
> there is no difference, however as soon as you get two
> hands (or minds) on that contribution there is
> collaboration and there's a potential issue.  Only one
> of you can submit the patch to JIRA or to SVN.
> Therefore only one of you has formally granted license
> to Apache.  There is no physical proof that the person
> who collaborated and has copyright of the material
> he's contributing or has granted sufficient license to
> Apache (or relinquished enough rights to another
> entity so that they may legally grant license to
> Apache) for inclusion of that code enhancement in the
> project and in all the liberal ways that Apache can
> use a contribution.  Without additional consideration,
> the person pressing the Apache grant radio button in
> JIRA is lying as they are not the "Licensor" and
> cannot enter the agreement.

Technically that little checkbox in Jira doesn't mean a thing, not  
one little thing. The only point of it is to be another safe guard  
that person contributing the artifact understands and makes it clear  
what they are doing.

In a way I wish it simply weren't there as it is often confusing  
because people see it a lot, but they often don't bother to read the  
document(s) that have real legal teeth.

All that matters is that someone who represents the copyright holder 
(s) gets the issue to a committer, the committer checks out the  
licensing, and then gets it into the repo. The Jira system just helps  
to make this more trace-able.

I HIGHLY recommend reading the Apache License 2.0, and the Individual  
Contributor License Agreement files. These clear up pretty much all  
of these questions.

> Because the Developers Conference is not an official
> Apache gathering, I would suspect any collaborated
> contribution would be a similar scenario to the
> sandbox scenario that is being discussed on the
> general-incubator ML, regardless of the level of
> involvement of a committer in the conference.  (If
> that were the case, I would just need to ask one of
> the committers to have involvement in the sandbox.  I
> don't think that is sufficient to cross the legal
> hurdle of who the licensor is.)

No, having a committer there doesn't solve the problem, but it sure  
helps and makes these contributions MORE legally reliable because the  
committer is sitting there watching it be created and has direct  
contact with all of the developers. When submitted through Jira  
alone, the committer has to trust the person who uploaded it or if it  
is a bigger or more suspicious patch then the committer has to do  
some research to make sure it is kosher.

> IANAL, and I'm not sure what the potential
> repercussions are. I'm simply asking you guys to
> consider what the potential repercussions are because
> it would be an obvious shame for all that hard work to
> have the potential to be subject to the scrutiny of IP
> law when we're all here just trying to contribute in
> the spirit of open source.

Yes, this is an important part of open source and something I've  
found necessary to study over the years. There are various good  
resources to help you understand the general concepts, and of course  
long hours of discussion of how to handle certain problems helps,  
like the discussion you're going through now about the sandbox  
implications.

Please understand that usually there is no sure fire way to make sure  
that code going into the repository is clean. The policies of the ASF  
are there to give it a good legal basis and a good chance in general.  
For small code bits that rely on other larger code bits already in  
the open source project the risk is fairly minimal. For big pieces  
developed elsewhere things get trickier because there is more risk of  
abuse, or in other words something slipping in that was not properly  
vetted for legal concerns. This is one of the reasons for the  
incubation process for larger pieces of code regardless of their  
source, and even if they are going into an existing project and not  
becoming a new project.

I hope that helps make clear the distinction, and the concern with a  
sandbox effort.

On the other hand, technically this is a problem you don't have  
yet... If something goes through months of development in the sandbox  
and is ready to go into the OFBiz trunk, THEN you'll have some legal  
hurdles to jump, but then you'll also have very specific information  
about the situation and it can be discussed with rubber to the road  
instead of in a hypothetical way. Still, what you're doing with  
regards to finding out about legal concerns is a good idea up front.  
Hopefully now you know what some of your options are and you can  
decide how to proceed.

-David