Incubation FAQ

This is an informal FAQ mostly drawn from conversations on the committee email list where we help projects through the OSGeo incubation process.

About Incubation

Projects Joining the Foundation

This is a working draft of the the OSGeo FAQ section for projects joining the foundation.

What software projects are currently part of the foundation?

On its formation, the GDAL/OGR, GeoTools, GRASS GIS, Mapbender, MapBuilder, MapGuide Open Source, MapServer and OSSIM projects declared their support, and joined as projects in incubation. Since then GDAL/OGR, GRASS GIS, Mapbender, MapBuilder, and MapGuide Open Source have graduated as full projects from this list. Further projects have entered incubation and some have also graduated. See the OSGeo Projects on the foundation website for an official list.

What does a project need to do to join?

Projects need to go through the Incubation process to join the foundation. Details on how to apply, and how the process works are available on the Incubator web page.

So when can my project join?

The Incubator is now accepting applications to join the foundation. Only a limited number of projects can be effectively handled in the incubation process at a time, so please be patient.

Do foundation projects need to sign over copyright to the foundation?

No. Copyright to individual contributions in foundation projects is expected to remain with the original developer. However, assigning copyright to the foundation is an available option.

Do project developers need to sign a legal agreement?

No. Generally speaking this is not required, but some specific projects may require developers or their employers to sign a contributor agreement.

Do foundation projects need to turn over project control to the foundation?

No. The foundation is not interested in controlling foundation projects. However, foundation projects are expected to follow some foundation rules, mostly around the need to ensure that project code is not legally encumbered (e.g., not stolen, or improperly contributed), and that appropriate controls are in place to ensure code is properly contributed. Some additional expectations may exist around projects operating in an open and accountable fashion, handling foundation-provided funding appropriately and not taking actions that will cause legal problems or negative goodwill for the foundation. The foundation also encourages, but does not require, projects to support foundation goals, such as implementing standards-based interoperability.

Can my project operate as a benevolent dictatorship?

No. OSGeo projects are typically governed by a Project Steering Committee (PSC). The PSC should operate openly and with a consensus based approach. While the PSC may delegate specific responsibilities to particular project members it is ultimately intended to be the governing body for the project. A benevolent dictatorship is not considered a suitable open and consensus based approach to governance.

Do I have to use mandated source control / web system / bug system / mailing list from the foundation?

No. Projects joining the foundation can continue to use their traditional source control system, web site system, bug tracker and mailing list software. However, the foundation does offer these infrastructural components, and encourages their use to provide a more consistent way for users and developers to interact with the different foundation projects.

Does the foundation mandate a particular license for software?

The foundation only accepts projects that use Open Source Initiative certified licenses for their software, and requires that projects stick to OSI-certified licenses. This includes common licenses such as MIT/X, BSD, GPL, and LGPL. The foundation encourages library projects to use the LGPL or a more permissive license (such as MIT/X or BSD) rather than the GPL so that the libraries can be reused by non-GPL projects, but does not require it. The foundation also discourages a proliferation of new and incompatible licenses.

Does the foundation mandate a particular license for content other than software, such as geodata, educational materials, documentation, etc.?

The foundation accepts non-software projects that use Creative Commons or similar licenses for their public geodata, educational material, or promotional material. The foundation also discourages a proliferation of new and incompatible licenses.

Q: What is incubation

Incubation in a process used to add projects to the Open Source Geospaital foundation. It is design as a quick safety check prior to a project being recognised as part of the foundation.

For more details see the main web page: http://www.osgeo.org/incubator

Q: Why have a mentor

The Incubation Committee committee asks for a mentor to assist each project through incubation for a number of reasons.

A: Outreach

We are making available a member of the committee on your developer email list as an out reach effort to your community. It is often easier to have discussions (on open source basics, or incubation checks) on the project email where everyone is comfortable

A: Privacy

Not all questions are suitable for public discussion. The incubation process can touch on a few subjects that should be handled with care (such as code ownership, code distribution, license questions and so forth). Having a mentor to talk (and arrange suitable help) can be very useful to collection the required information to continue.

Projects

Q: What about long term viability?

A: The incubation process really wants to check that a project is not going to suddenly disappear:

• That a project has a high bus number and will not suddenly end if a central key developer leaves or is no longer available
• That a project draws on several organisations (and thus sources of funding) for its health and well being

Q: What about existing projects

A: Existing projects answer to the board

Incubation is a dynamic process reflecting the needs of the foundation today. The incubation process and checklists are updated to reflect these changes and are adjusted as the foundation priorities change.

Existing projects are not expected revisit the incubation process they are answerable directly to the board via a "project officer". If the board requires any additional information or policy change suitable arrangements can be made.

Open Source Basics

Q: Open Source License?

A: Recognised by Open Source Initiative

It is not enough to give the source code away for free - projects are expected to be open source in license.

For the purposes of incubation that amounts to the projects being distributed under a license recognised here:

• http://opensource.org/

Q: Attribution and Agreement

A: Who wrote it and did they agree to let you distribute it

On the face of it this is a real easy check to understand - but a very hard one to get correct. Projects receive input in large part through contributors and committers; supplemented by patches submitted via issue trackers.

Some projects allow contributors to keep their own (c) and simply ask that all contributions be provided under a common license. Other projects ask that copyright be assigned to a common organisation this allows the project to change license in the future if needed.

Common mistakes:

• It is common for projects to get in trouble with individuals contributing fixes; while working as an employee. In these cases the employees often owns the contribution and a separate code contribution agreement must be filled in by the employer.
• It is common from working code to be picked up from one project and used to fix an issue in another. Care must be taken to ensure the licenses compatible or suitable arrangements have been made.

Examples:

• PostGIS contributions are made under a common license with no copyright assignment
• GeoTools contributions are made after a developer has signed a code contribution to the OSGeo Foundation
• GDAL commiter guidelines has a legal section stressing the responsibility to ensure the code is appropriately contributed. GDAL expects new commiters to publically acknowledge that they have read the guidelines and will endevour to adhere to them (on public mailing list).
• GeoServer contributions are assigned to the Open Planning Project
• GeoTools has a standing arrangement with GeoServer allowing code to be contributed; in each case an email request is made and formally responded to prior to a fix being back ported to GeoTools. This is a case of a procedure being established allowing the license of the code to be changed from GPL to LGPL.

This is often checked against file headers and verified using version control history, issue tracker history and any written records such as code contribution agreements.

A: Example of a Code Contribution Agreement

Open Development

Perhaps the most important indicattor of long term viability is how well a project practices open development.

We are really looking for two things: - evidence that the procedures are in place allowing the project to be run by several organisations as a collaboration - ensuring new groups can take part

While this is sometimes considered a tall order we do ask that projects write down how they are functioning - even if it is inconvenient for others. OSSIM often had key decisions made over breakfast in a monthly face to face meeting. The direction for GeoNetwork was often set by key stakeholders meeting face to face each year. In both these cases taking part is open to new members.

Checks

Q: Why check Email List Activity

A: Confirm open communication

Mentors sign up to the developer and email lists to look for a healthy interaction between developers and users. We are especially looking for evidence of collaboration between organisations.

A: Confirm open decision making

A key component of open development is ensuring that the project procedures are applicable to all groups taking part in the project. This is often really illustrated around accepting new contributors, planning future development and making new releases.

Note:

• We do expect gaps (and understanding) around the careful balance between meeting paying customers expectations while still maintaining open communication with the community. As such we are used to see pending work proposed (and checked with the community) and then withdrawn if the appropriate funding was not obtained.

Q: What to look for in headers

A: That they exist and that the correctly attribute the code and establish the project is allowed to distribute

Headers are your life lifeline if any legal questions are asked around your project. At a minimum they should provided copywriter and license information.

Examples:

• (FAIL) Missing header
• (FAIL) Header indicating the file was copied and pasted from the Sun JRE source code
• (SUCCESS) GeoTools User Guide listing both source and documentation licenses. Mix of licenses discovered during incubation - highlights include how to handle "one off" licenses (SOSNOKILLLICENSE and Happy Fun Ball License)
• (SUCCESS) GeoTools Developer Guide Examples showing how to attribute prior work; adjust code when changing license and more

Q: Sample data licensing?

You should double check that you have permission to distribute the sample data included with your application or documentation. Even it is just toy data included with your source code for test cases.

A: If you are unsure where the data came from

You can mention that the sample data is of unknown license; raise an issue in your issue tracker to sort out, and proceed to graduation.

A: If you know where the data came from.

Other projects (in their review) tend write down where the data came from - often taking steps to thank the organisation that provided the data.

Examples

• (FAIL) Early uDig included some sample data from an ESRI product (simply because that was the data used for testing). The project pulled those releases when the problem was noticed.
• (SUCCESS) The live DVD is distribution the natural earth dataset and mention that the license is public domain.