On Jan 7, 2007, at 11:18 AM, Chris Howe wrote:
--- Anil Patel <[EMAIL PROTECTED]> 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 PatelIf 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
smime.p7s
Description: S/MIME cryptographic signature
