Guidelines for OWASP Projects

This page is maintained by the OWASP Project Task Force to help assist Project Leaders with information about successfully running an OWASP Project. It will be updated from time to time, and changes will be discussed and announced on the OWASP-Leaders list.

Project Wiki Pages

• When a new project is started, we will create a wiki page as the official homepage for your project. It will contain the [[Category:OWASP Project]] tag at the bottom. Please ensure this tag stays on your project homepage.

• Project wiki pages will also be listed in the appropriate category on the OWASP Projects page, which means that, initially, until being assessed, it will be placed alphabetically within the ‘Alpha Status Projects’ category. Exceptions can be made for special circumstances (e.g. pre-established project being brought into OWASP), so contact the OWASP Global Projects Committee for more information.

• We'll start your project homepage with a Project Identification template to capture the relevant meta-data that you already provided about your project. For example, the Live CD Project page contains the source code {{Template:OWASP Live CD Project}} and the template is automatically embedded on the project page.

• You may move your Project Identification template anywhere you'd like (top/bottom of the page, to a separate tab, etc.) but please ensure it stays linked from your project's page. If you really would like it to be out of the way, you can just edit the Project Identification page and tag it with your project's category label, such as [[Category:OWASP Enterprise Security API]], and then no link on your project's homepage is required.

• Your project homepage belongs to your project and you are free to design it as you like (some good examples of different styles include the ESAPI Project page and the Live CD Project page). It's usually a good idea to include information about your project including detailed descriptions, screenshots, download links, a link to the project mailing list, contact information for the project leader, and any other relevant information.

• You can have as many wiki pages as you want to support your project. Please feel free to create them yourself. Everything posted on the wiki is accessible by many people around the world.

• If you have never edited a wiki, take a quick look at the this cheat sheet for basic editing help. Also, OpenOffice is a free office suite which includes the ability to export to MediaWiki text. The exported text file contents can be copied and pasted into OWASP's wiki.

Project Sponsorship

Many OWASP projects are made more successful through contributions from sponsor organizations that donate money or man-power. But, managing sponsorship attribution over time can become tricky, so here are some general guidelines for project leaders based on common cases:

• In cases where sponsors contribute materials governed by an open-source license that requires attribution, Project Leaders should ensure that attribution is done accordingly. In such instances, it may also be necessary to attribute individual contributors.

• For financial contributions to a project (e.g. an outside organization donating through OWASP Season of Code sponsorship), sponsors should be attributed for at least 1 year. After that, Project Leaders are free to leave or remove the sponsorship attribution.

• Sponsors can be attributed by name or through display of their logo. This can appear on the project homepage or built in to the document/tool itself. This is the choice of the Project Leader.

Project Licensing

For OWASP projects, the materials are available under an approved FLOSS (Free, Libre and Open Source Software) license. For more information, please see the OWASP Licenses page. Some other items to consider when choosing a license:

• For documentation projects, the Creative Commons Attribution ShareAlike 3.0 license is good choice as that license was designed for creative endeavors such as written works.

• For tools and other coding projects, an approved FLOSS license is recommend as these were designed for software creation. Examples of FLOSS licenses for coding projects are:
  • GNU GPL (version 3 and version 2)
  • BSD License (aka modified or 3-clause BSD license see section 2.2 for an example)
  • Apache 2.0 License (license text)

When choosing a software license, the primary difference between licenses deals with the restrictions and permissions enforced by the license. The restrictions and permissions enforced by the chosen license can have impacts on business adoption and contributions by the community at large. Consideration should be given to existing and well established licenses as these are much better understood by the IT and business community in general. For more assistance on selecting a license, here are some general references:

• The Free Software Foundations licenses page. The FSF authored the GPL licenses.
• The Open Source Initiative's licenses page ordered by category.
• A podcast on selecting a FLOSS license.
• The Software Freedom Law Center can provide advice on license selection as well.

OWASP Recommended Licenses

Why are you recommending these licenses?
Which other open source licenses are eligible for an OWASP project?

Choosing a license under which an artifact is distributed and enforcing the license are prerogatives of the copyright holders over that artifact. By default, each contributor is copyright holder over the contributed piece. Contributors must all agree on the license and cooperate in enforcing it or must assign their copyright to the entity which becomes responsible for choosing and enforcing the license.

OWASP is a collaborative initiative for the public good and most of its output is expected to be functional, rather than aesthetic. The problem OWASP tackles is so large that OWASP acknowledges a need to collaborate with the commercial world. Therefore, in order to become an OWASP Sponsored Project, you should be comfortable with:

• Allowing arbitrary uses for your work, for example for commercial purposes. (If you disagree, consider using CC-BY-NC.)
• Revealing to the world your project's source code (its form preferred for modification).
• Allowing your work, under certain conditions (see below), to be modified by others and redistributed. (If you disagree, consider using CC-BY-ND.)

How to choose a license for artifcts of your OWASP project

Artifact		Under what conditions can your work be modified and redistributed?
		As long as modifications are licensed in the same spirit	If credit is appropriately given to you	Under any circumstances
Standalone Tool	Run locally	GPL (newest version as of 2016 is 3.0) The "General Public License" protects users' four essential freedoms, among other things by requiring someone who distributes software derived from yours to also publish the source code for the modifications. Anyone can charge money for distributing copies of the software, but cannot prevent its recipients from redistributing it for free. The GPL allows the copyright holders to distribute the software under additional licenses, too, which can be a way to make it proprietary-friendly.	Apache License (newest version as of 2016 is 2.0) Has the fewest restrictions, even allowing proprietary modifications and proprietary forks of your project, and is more up-to-date than the BSD license.	CC0 (newest version as of 2016 is 1.0) The "Public Domain Dedication" means that anybody can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
	Consumed over the network	AGPL (newest version as of 2016 is 3.0) The "Affero General Public License" extends the GPL to SaaS: users of the modified software must be able to obtain the source code of the modifications.
Library		GPL or LGPL (newest version as of 2016 is 3.0) The "Lesser General Public License" relaxes the GPL for libraries: if the library is not modified, just integrated (function calls, global variables,...), with other software, it does not require the source code of the other software to be published. The Free Software Foundation recommends the LGPL only for libraries which have established competitors for the same functionality, otherwise they recommend the full GPL.
Document (includes E-Learning, presentations, books etc.)		CC-BY-SA (newest version as of 2016 is 4.0) The "Creative Commons Attribution-ShareAlike" is like the GPL, but for documents.	CC-BY (newest version as of 2016 is 4.0) The "Creative Commons Attribution" is like the Apache License, but for documents.