Skip to content

Latest commit

 

History

History
109 lines (83 loc) · 4.45 KB

Licensing.md

File metadata and controls

109 lines (83 loc) · 4.45 KB
Raw

Licensing

Licensing defines the reuse and permissions around the project's code. A project license defines how someone may use or redistribute a project's intellectual property (IP). A contributor license agreement (CLA) defines the terms under which a contributor grants a project the right to use and redistribute their IP.

  1. Why Document It?
  2. How To Document It?
    1. Outbound License
    2. Inbound License
  3. Example Licenses
    1. Example Outbound Licenses
    2. Example Inbound Licenses
  4. References

Why Document It?

First, licensing your software appropriately can help protect you from various kinds of warranty claims by users and limit your liability.

Second, a software license can limit how someone uses your software. More permissive licenses (like MIT and Apache 2) allowing modification and even closed-source distribution and monetization. More restrictive "copyleft" licenses (like GPL-3) require that copies and modified versions of the software be kept open source and under the same license.

Finally, dictating the terms under which a contributor may grant rights in their IP to a project can help disambiguate ownership and keep a project's code flexible to change.

How To Document It?

Two de-facto standards exist for documenting both outbound and inbound licenses.

Outbound License

GitHub expects a project's license to exist in a LICENSE.txt or LICENSE.md file in the root of your project's source code repository.

Choose a License is a great resource for helping guide you through this decision. Adobe recommends using Apache 2 for most projects, but MIT is also acceptable for documentation and sample code.

Inbound License

It is best to document whether you require an inbound license, also known as a CLA, in your project's CONTRIBUTING.md. The Adobe open source starter repo's CONTRIBUTING.md calls this out near the top of the document.

Adobe projects going open source and into the public need to have external contributors sign Adobe's CLA before contributions from them can be accepted.

Most small-scale open development projects don't need a CLA as services like GitHub by default treat the outbound license as the inbound license.

Example Licenses

Example Outbound Licenses

On the "copyleft" spectrum, requiring that distributions of copies and modified versions of the software remain open source:

On the more permissive spectrum, allowing modification, commercialization and redistribution:

Example Inbound Licenses

References

  1. choosealicense.com
  2. Adobe's CLA
  3. Microsoft's CLA
  4. Canonical's CLA
  5. GitHub Licensing Help Article
  6. GitHub Inbound=Outbound Terms of Service
  7. Adobe's Open Source Office's Starter Repo's CONTRIBUTING.md
  8. MIT License
  9. Apache 2 License
  10. GPL 3 License
  11. BSD 3 Clause License
  12. Adobe's Open Source Guidelines For Use In Adobe Products