Skip to content

Latest commit

 

History

History
70 lines (54 loc) · 5.79 KB

licenses.md

File metadata and controls

70 lines (54 loc) · 5.79 KB

For The Blockspace Symmetry hackathon (Berlin, 19-21.08), all submissions are required to be open source. This means that you will need to specify any one of these licenses for your project, including in the README of your GitHub submissions and in any other material you create (e.g., artwork or images). Here's a brief guide to help hackers decided which license is most appropriate for their use cases.

Why Choosing the Right License Matters for Web3 Development

When developing in the Web3 space, selecting the appropriate open-source license is crucial. Here's why:

  • Decentralization and Transparency: Web3 projects thrive on decentralization and transparency. Open-source licenses foster trust and community engagement by allowing anyone to inspect, modify, and contribute to the code.
  • Interoperability: Ensuring your project can work seamlessly with other open-source Web3 projects is vital. Some licenses may be more compatible with others, affecting how easily your project can integrate with existing solutions.
  • Innovation and Collaboration: Open-source licenses encourage collaboration, enabling faster innovation. By making your code accessible, you invite developers worldwide to contribute, improving and expanding your project.
  • Legal Protection: Some licenses offer protections against patent claims and other legal issues, which can be particularly important in the rapidly evolving Web3 landscape.

Opportunities from an Open Source Code Base

Adopting an open-source approach for your Web3 project can unlock numerous opportunities:

  • Community Building: Create a vibrant community around your project, attracting contributors and users who can help drive the project's growth.
  • Rapid Development: Leverage the collective expertise of the open-source community to identify and fix bugs, add new features, and optimize performance.
  • Visibility and Trust: Open-source projects often gain more visibility and trust, which can attract partnerships, funding, and broader adoption.
  • Education and Skill Development: Contributing to open-source projects helps developers improve their skills and knowledge, fostering a culture of continuous learning and improvement.

Understanding these licenses and their implications can help in making informed decisions about the licensing of your software projects.

1. MIT License

  • Permissive: Allows virtually unrestricted freedom to use, modify, and distribute the software.
  • Conditions: Requires attribution and inclusion of the original license text.
  • Use Case: Popular for a wide range of projects due to its simplicity and permissiveness.

2. Apache License 2.0

  • Permissive: Similar to the MIT License, but includes an explicit grant of patent rights.
  • Conditions: Requires attribution, inclusion of the original license text, and disclosure of significant changes.
  • Use Case: Commonly used for projects needing patent protection, such as Apache projects.

3. BSD Licenses (2-Clause and 3-Clause)

  • Permissive: Allows similar freedoms to the MIT License.
  • Conditions: 2-Clause requires attribution; 3-Clause adds a non-endorsement clause.
  • Use Case: Often used in academic and enterprise settings.

4. GNU General Public License (GPL)

  • Copyleft: Requires that any derivative works be licensed under the GPL.
  • Conditions: Must provide source code and keep derivative works under GPL.
  • Use Case: Used for projects where the goal is to ensure freedom to use, modify, and share is preserved, like the Linux kernel.

5. GNU Lesser General Public License (LGPL)

  • Weak Copyleft: Allows linking with proprietary software while ensuring modifications to the LGPL-covered parts remain free.
  • Conditions: Modifications must be licensed under LGPL, but can be linked with non-LGPL software.
  • Use Case: Suitable for libraries that may be used by proprietary applications, such as the GNU C Library.

6. Mozilla Public License (MPL) 2.0

  • File-level Copyleft: Requires modified files to be open source but can be combined with proprietary code.
  • Conditions: Modifications to MPL-covered files must be made available under MPL.
  • Use Case: Used by projects like Mozilla Firefox, balancing openness and commercial use.

7. Eclipse Public License (EPL)

  • Weak Copyleft: Similar to MPL, allows combining with proprietary code.
  • Conditions: Modifications must be made available under EPL.
  • Use Case: Common in the Eclipse development community.

8. Creative Commons Licenses (CC0, CC BY, CC BY-SA)

  • Permissive/Copyleft: Range from very permissive (CC0) to more restrictive (CC BY-SA).
  • Conditions: Varies by type; CC0 (public domain), CC BY (attribution), CC BY-SA (share-alike).
  • Use Case: Often used for content rather than code, such as documentation and media files.

9. Public Domain Dedication (CC0)

  • Permissive: Places the work in the public domain, removing all restrictions.
  • Conditions: None.
  • Use Case: When creators want to relinquish all rights and ensure maximum freedom.

10. Common Development and Distribution License (CDDL)

  • Weak Copyleft: Similar to MPL, allows combining with proprietary code.
  • Conditions: Modifications to CDDL-covered files must be made available under CDDL.
  • Use Case: Used by projects like the OpenSolaris operating system.