HANDBOOK: Document copyright transfer

[stevespringett]

No mention of copyright transfer. We should discuss this in a future committee meeting, decide on a path forward and document the requirements in the handbook.

[thc202]

This might help: https://www.apache.org/licenses/contributor-agreements.html

IMO another thing OWASP should have is ICLA/CCLA.

[hblankenship]

We have the 2013 and 2014 project handbook which most project leaders either signed prior to 2018 or else signed digitally through acknowledgement on the project submittal form. The agreements indicated there will be included here.

[hblankenship]

Here is the leader agreement that we have had in place since at least 2013, modified to be in the new handbook: Leader Agreement By submitting the new project request and clicking the box that you have read the project handbook, you and the Foundation hereby accept and agree to the following terms and conditions:

1. The donation or creation of your project means that you agree to hand over all past, present and future contributions of source code and documentation to the Foundation, however submitted to the Foundation, excluding any submissions that are conspicuously marked or otherwise designated in writing by You.

2. You hereby grant to the Foundation a non-exclusive, irrevocable, worldwide, no-charge, transferable copyright license to use, execute, prepare derivative works of, and distribute (internally and externally, in object code and, if included in your Contributions, source code form) your Contributions. Except for the rights granted to the Foundation in this paragraph, You reserve all right, title and interest in and to your Contributions. OWASP will always release a free and open version of anything we distribute that includes your Contributions.

3. You may continue to be involved in the donated project, but you may not withdraw your project from the OWASP Foundation once the project donation process has been completed.

4. You represent that you are legally entitled to grant the above license. If your employer(s) have rights to intellectual property that you create, you represent that you have received permission to make the Contributions on behalf of that employer, or that your employer has waived such rights for your Contributions to the Foundation.

5. You represent that, except as disclosed in your Project Donation submission(s), each of your Contributions is your original creation. You represent that your Contribution submission(s) include complete details of any license or other restriction (including, but not limited to, related patents and trademarks) associated with any part of your Contribution(s) (including a copy of any applicable license agreement). You agree to notify the Foundation of any facts or circumstances of which you become aware that would make Your representations in this Agreement inaccurate in any respect.

6. You are not expected to provide support for your Contributions, except to the extent you desire to provide support. You may provide support for free, for a fee, or not at all. Your Contributions are provided as-is, with all faults, defects, and errors, and without warranty of any kind (either express or implied) including, without limitation, any implied warranty of merchantability and fitness for a particular purpose and any warranty of non-infringement.

[stevespringett]

I think this is an issue:

non-exclusive, irrevocable, worldwide, no-charge, transferable copyright license

We need to prevent foundation exits going forward. I would recommend that the project committee define its "ideal state" and seek Council to advise if the existing agreement can achieve the ideal state. If not, then we'll need the language updated.

In all cases, we'll need to keep records and governance in place. I'm certain that I did not personally sign any agreement for three of my OWASP projects. Governance is key.

[stevespringett]

@bkimminich if you agree with the above, please add this to the agenda of a future project committee meeting.

[secureideas]

I think if our goal is to prevent "project exits" doing it via lock in is the wrong way to do it. This is a horrible approach in my opinion.

[secureideas]

I also know that I did not sign anything for my project when it was included in OWASP.

[bkimminich]

I think if our goal is to prevent "project exits" doing it via lock in is the wrong way to do it. This is a horrible approach in my opinion.

OWASP can't accept any "come and go as you please" behavior. The worst case would be some project joining OWASP to get a visibility boost, maybe even some funding, and then leave to pursue commercial endeavors.

Through OWASP's required soft OSS licenses (Apache 2, MIT etc.) any project should be easy to fork and continue elsewhere, and that is exactly what leavers should do by default. That way leaver cases are handled the same way as abandonment cases, and that makes governance easier as a whole in my opinion.

OWASP could then still decide to archive the original repository and point people to the new version fork. And special agreement cases of full transfer could still happen regardless, but they'd be documented as an exception.

[bkimminich]

This "fork if you want to leave" approach obviously can only be enforced easily in projects under the main OWASP GitHub org. Projects with their own orgs or under private accounts will not want to do the forking as that'd make them restart with zero GitHub stars. But that's where negotiating and special agreements would need to happen, otherwise legally OWASP should either get the dedicated project org or get the original repos transfered into github.com/owasp, so the project can fork them back into their original org. This is all not pretty, but should still be solvable.

[thc202]

We need to prevent foundation exits going forward.

You can't prevent that, all(?, at least coding) projects will always be free to "exit" whenever they want, that's the point of OSS licenses.

I'm going to mention again ICLA/CCLA, it's not just about the leader agreeing to something (if they actually signed), third party contributions that happen thereafter also need to be under an agreement.

[hblankenship]

You digitally sign the agreement when you click the 'I have read and agree to blah blah' on the project submission form.

[secureideas]

@hblankenship If you read the site at https://owasporg.atlassian.net/servicedesk/customer/portal/7/create/70?src=-1419759666 which is what "Start a New Project" on OWASP.org links to, the terms links to:

"I have read, understand, and will abide by the guidelines in the Project Handbook*

Yes https://www.owasp.org/images/d/d8/PROJECT_LEADER-HANDBOOK_2014.pdf"

When I go to the PROJECT_LEADER_HANDBOOK_2014.pdf, it explicitly says that "OWASP does not require a transfer of ownership" so I really don't know what you are saying here.

[psiinon]

Trying to lock projects into OWASP is a VERY bad idea. I think it will severly limit the number of 'good' OSS projects that will want to join OWASP. The focus should be on making OWASP the best place for security projects so that they dont want to leave.

Why do projects leave? I think there are 2 cases:

1. A (startup) company donates its OSS code to OWASP for the publicity boost and then when adoption increases takes it back to make more money. This is an abuse case which you should be aiming to prevent.

2. A 'real' OSS project isnt getting the support they need from OWASP, as per ZAP. ZAP is a big project. I do not believe that it can be maintained in ones spare time - we need full time people on it. I got funding from a couple of startups but that didnt last. OWASP is not set up to either fund devs or finding the funds for devs - if it was then we wouldnt have had to leave. We had to find another foundation that is being set up to pay devs to work fulltime on OSS security projects. In our case it really wouldnt have mattered whether we had signed over rights to OWASP or not. We need funding and without it I think we would have had to shut ZAP down. So if we had signed over the rights to ZAP then we would have just had to fork ZAP. OWASP ZAP would be dead - I really dont think anyone else could have kept it going.

[hblankenship]

I agree with Simon in that locking projects into OWASP isn't a good idea and my comments are not to suggest that was ever the intent of the previous agreements. I believe that the agreements were attempting to 1.) allow the project leaders to maintain ownership of the project itself, including the ability to fork it away and 2.) protect OWASP in that the project will ALWAYS be available from OWASP (if the Foundation chooses) and so OWASP can continue to maintain and distribute said project - though I do not know that this is grounded in reality (per Simon's last sentence above). And IF someone really wanted to create a new 'zap' in OWASP, well they could fork the current ZAP themselves at some point in the future.

The problem here is that the benefits of being associated with OWASP are front-loaded; I mean that many projects get a great deal of benefit from being an OWASP project until such point that the project is sufficiently 'popular' that the association is less needed. What a project leader does at that point is self determined.

There DOES need to be a way to better protect OWASP from case 1 above (whether a startup company or individual), though, and I don't see a good way of doing it without also affecting case 2. Except how it is currently stated - the leaders are required to fork the code and move along; the way these larger projects are set up, currently, make this too large a burden, to be fair, on those projects. Moving forward, I foresee OWASP requiring future projects of this size to move into an OWASP-controlled org (for instance, zap would have been under owasp-zap instead of zaproxy and Simon would have been an admin but not an owner). Thoughts on this approach?

And, yes, also a determination of what to do to keep projects moving forward without resorting to being a development house. But that's not the point of this handbook issue and is in other hands.