2.4 KiB
| layout | permalink | redirect_from | title |
|---|---|---|---|
| default | /community/ | /existing/ | Existing projects and communities |
If you're contributing to or extending an existing project, it's almost always easiest to continue using that project's license. To find its license, look for a file called LICENSE or COPYING, and skim the project's README. If you can't find a license, ask the maintainers.
Depending on the original project's license, using the same license might be a requirement, not just the easiest thing to do. (See the "same license" condition of some licenses.)
Some communities have strong preferences for particular licenses. If you want to participate in one of these, it will be easier to use their preferred license, even if you're starting a brand new project with no existing dependencies. Some examples include:
{: .bullets}
- Apache requires Apache License 2.0
- Cloud Native Computing Foundation dictates Apache License 2.0 by default
- GNU recommends GNU GPLv3 for most programs
- npm packages overwhelmingly use the MIT or the very similar ISC licenses
- OpenBSD prefers the ISC License
- Rust crates are overwhelmingly licensed under both MIT and Apache License 2.0
- WordPress plugins and themes must be GNU GPLv2 (or later)
Communities come in all shapes and sizes, and more than one community might be pertinent (e.g., keep in mind your company if you work for one). The examples above are very well established. If the community you're building a project for doesn't have set-in-stone licensing traditions, or you don't see your project as part of any particular community, that's fine: make your own choice of an open source license.