foss

This page is no legal advise.

FOSS (Free and Open Source Software) notes

Interesting Licences

• CC0
  • Also suitable for software
• GPL v3
  • Note on the COPYING file; it usually contains the licence text (for multiple licences you can write COPYING.GPL etc.) or a note about the licence (see the Linux kernel as an example)
• MIT
• Apache v2
  • Requires a NOTICE file
• MPL v2
  • good tradeoff between Apache and GPL v3
• BSD 3-clause (aka Modified BSD licence)
• Creative Commons (all kinds)
  • Documentation purposes

Compare Licences

• GNU GPL compability of several FOSS licences; contains short explanations about important points of those
• Quick non-legal overview
• Licences by category (open source initiative)
• Table overview
• Overview on Wikibooks
• MIT, Apache, BSD 3-clause compared

Public domain

Public domain is not accepted in all countries. Consider CC0 instead

Documenting licences

Code boilerplate

In some licences this is required (like GPL).

If not it is good practice to include a short header in each file stating:

• Autor name(s) + email address
• Licence: full name + link

Licence naming | SPDX

Software Data Package Exchange (SPDX) is an open standard to name/identify licences, copyrights, etc.

A list of licences and their accompanying identifiers can be found here. In the dependency documentation I prefer to state both the SPDX identifier plus the whole name of the licence.

A good guide about SPDX esp. in terms of documentation can be found here.

Copying from Stack Overflow

User content is licenced unter a CC-BY-SA licence.

Excerpt from the above link:

If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

Some articles:

• "What is the license status of StackOverflow code snippets?"
• SO Terms of Service

Attribution

CC best practices

Best practices for attribution of CC licenced content

Examples - inline

"""
MIT License toHumanReadable
Copyright (c) 2019 Marcel Schmalzl, Steve Göring
https://github.com/TeamFlowerPower/kb/wiki/humanReadable
"""

CLAs

This topic it's worth endless discussions. Mostly a good trade-off the DCO (Developer Certificate of Origin ) (founded by the Linux Foundation in 2044). The DCO is a very lightweight mechanism and lowers the barrier for external contributions. For the Linux Kernel development it is in use since ages (example commit).

Some additional ressources:

• CLA Problems described by Richard Fontana
  • "Richard is Senior Commercial Counsel on the Products and Technologies team in Red Hat's legal department. Most of his work focuses on open source-related legal issues."
• DCO vs. CLA (esp. the lower part is mostly interesting)

Documentation

Anatomy of an open source project

The content of this chapter is based on github.com/github/opensource.guide used under the CC-BY-4.0 license.

A typical open source project has the following types of people:

• Author: The person/s or organization that created the project
• Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
• Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. (They may also be authors or owners of the project.)
• Contributors: Everyone who has contributed something back to the project.
• Community Members: People who use the project. They might be active in conversations or express their opinion on the project’s direction. Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information.

A project also has documentation. These files are usually listed in the top level of a repository.

• LICENSE: By definition, every open source project must have an open source license. If the project does not have a license, it is not open source.
• README: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
• CONTRIBUTING: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
• CODE_OF_CONDUCT: The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
• Other documentation: There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.

For more information see here

Contribution guides

It is helpful to write contribution guides in order to assist contributors with your workflows. A good examples you be found for the Linux kernel

An example of a good CONTRIBUTORS/MAINTAINERS file can be found here