Skip to content

Commit 4e9e7c5

Browse files
maennchenmaennchen
committed
Implement Open Source Policy
1 parent f1bf1b8 commit 4e9e7c5

File tree

2 files changed

+220
-0
lines changed

2 files changed

+220
-0
lines changed

‎OPEN_SOURCE_POLICY.md‎

Lines changed: 158 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,158 @@
1+
# Open Source Policy
2+
3+
## 1. Introduction
4+
5+
This Open Source Policy outlines the licensing, contribution, and compliance
6+
requirements for all code released under the Elixir project. By adhering to
7+
these guidelines, we ensure that our community, maintainers, and contributors
8+
uphold both legal and ethical standards while fostering a collaborative,
9+
transparent environment.
10+
11+
This policy exists to support and protect the Elixir community. It aims to
12+
balance openness, collaboration, and respect for all contributors’ rights,
13+
ensuring that Elixir remains a trusted and innovative open source project.
14+
15+
## 2. Scope
16+
17+
This policy applies to the Elixir Programming language, located at
18+
https://github.com/elixir-lang/elixir. It covers every file, and contribution
19+
made, including documentation and any associated assets.
20+
21+
## 3. Licensing
22+
23+
All code released by the Elixir team is licensed under the
24+
[Apache-2.0](./LICENSES/Apache-2.0.txt) license. Additionally, the following
25+
licenses are recognized as permissible in this project:
26+
27+
- The Unicode license, as documented at
28+
[LicenseRef-scancode-unicode](./LICENSES/LicenseRef-scancode-unicode.txt)
29+
- The Elixir Trademark Policy, as documented at
30+
[LicenseRef-elixir-trademark-policy](./LICENSES/LicenseRef-elixir-trademark-policy.txt)
31+
32+
These licenses are considered acceptable for any files or code that form part of
33+
an Elixir repository. If a contribution requires a different license, it must
34+
either be rejected or prompt an update to this policy.
35+
36+
## 4. Contributing to Elixir Projects
37+
38+
Any code contributed to Elixir repositories must fall under one of the accepted
39+
licenses (Apache-2.0, Unicode, or Elixir Trademark). Contributions under any
40+
other license will be rejected unless this policy is formally revised to include
41+
that license. All files except those specifically exempted (e.g., certain test
42+
fixture files) must contain SPDX license and copyright headers
43+
(`SPDX-License-Identifier` and `SPDX-FileCopyrightText`). If a file qualifies
44+
for an exception, this must be configured in the ORT (Open Source Review Toolkit)
45+
configuration and undergo review.
46+
47+
Contributions must not introduce executable binary files into the codebase.
48+
49+
Every Elixir project within the organization will have an automated GitHub
50+
Action to enforce these rules. This mechanism aids in detecting non-compliant
51+
licenses or files early in the review process.
52+
53+
## 5. Preservation of Copyright and License Information
54+
55+
Any third-party code incorporated into Elixir projects must retain original
56+
copyright and license headers. If no such headers exist in the source, they must
57+
be added. This practice ensures that original authors receive proper credit and
58+
that the licensing lineage is preserved.
59+
60+
## 6. Objectives
61+
62+
The Elixir project aims to promote a culture of responsible open source usage.
63+
Specifically, our objectives include:
64+
65+
### 6.1 Clearly Define and Communicate Licensing & Compliance Policies
66+
67+
We will identify and document all third-party dependencies, ensure that license
68+
information is communicated clearly, and maintain a project-wide license policy
69+
or compliance handbook.
70+
71+
### 6.2 Implement Clear Processes for Reviewing Contributions
72+
73+
We will provide well-defined contribution guidelines. We utilize adopt a
74+
Developer Certificate of Origin (DCO) for additional clarity regarding
75+
contributor rights and obligations.
76+
77+
### 6.3 Track and Audit Third-Party Code Usage
78+
79+
All projects will implement a Software Bill of Materials (SBoM) strategy and
80+
regularly verify license compliance for direct and transitive dependencies.
81+
82+
### 6.4 Monitor and Continuously Improve Open Source Compliance
83+
84+
We will conduct periodic internal audits, integrate compliance checks into
85+
continuous integration (CI/CD) pipelines, and regularly review and refine these
86+
objectives to align with best practices.
87+
88+
## 7. Roles and Responsibilities
89+
90+
### 7.1 Core Team Member
91+
92+
Core Team Members are responsible for being familiar with this policy and
93+
ensuring it is consistently enforced. They must demonstrate sufficient
94+
competencies to understand the policy requirements and must reject or request
95+
changes to any pull requests that violate these standards.
96+
97+
### 7.2 Contributor
98+
99+
Contributors are expected to follow this policy when submitting code. If a
100+
contributor submits a pull request that does not comply with the policy
101+
(e.g., introduces a disallowed license), Core Team Members have the authority to
102+
reject it or request changes. No special competencies are required for
103+
contributors beyond awareness and adherence to the policy.
104+
105+
### 7.3 EEF CISO
106+
107+
The CISO designated by the Erlang Ecosystem Foundation (EEF) provides oversight
108+
on queries and guidance regarding open source compliance or legal matters for
109+
Elixir. The CISO is responsible for checking ongoing compliance with the policy,
110+
escalating potential violations to the Core Team, and involving legal counsel if
111+
necessary. This role does not require legal expertise but does involve
112+
initiating legal or community discussions when needed.
113+
114+
## 8. Implications of Failing to Follow the Program Requirements
115+
If a violation of this policy is identified, the Elixir Core Team will undertake
116+
the following actions:
117+
118+
## 8.1 Review the Codebase for Additional Violations
119+
We will investigate the codebase thoroughly to detect any similar instances of
120+
non-compliance.
121+
122+
## 8.2 Review and Update the Process or Policy
123+
In collaboration with the EEF CISO, the Elixir Core Team will assess the policy
124+
and our internal workflows, making any necessary clarifications or amendments to
125+
reduce the likelihood of recurrence.
126+
127+
## 8.3 Notify and Train Core Team Members
128+
We will ensure that all active Core Team Members are informed about any policy
129+
changes and understand how to apply them in everyday development.
130+
131+
## 8.4 Remove or Replace the Offending Code
132+
If required, we will remove or replace the non-compliant code.
133+
134+
## 9. Contact
135+
136+
The project maintains a private mailing list at
137+
[[email protected]](mailto:[email protected]) for handling licensing
138+
and policy-related queries. Email is the preferred communication channel, and
139+
the EEF CISO will be included on this list to provide assistance and ensure
140+
timely responses. While solutions may take longer to implement, the project
141+
commits to acknowledging all queries within five business days.
142+
143+
## 10. External Contributions of Core Team Members
144+
145+
When Core Team Members contribute to repositories outside Elixir, they do so in
146+
a personal capacity or via their employer. They will not act as official
147+
representatives of the Elixir team in those external contexts.
148+
149+
## 11. Policy Review and Amendments
150+
151+
This policy will be revisited annually to address new concerns, accommodate
152+
changes in community standards, or adjust to emerging legal or technical
153+
requirements. Proposed amendments must be reviewed by the Core Team and, if
154+
necessary, by the EEF CISO. Any significant changes will be communicated to
155+
contributors and made publicly available.
156+
157+
*Effective Date: 2025-02-14*
158+
*Last Reviewed: 2025-02-14*

‎README.md‎

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,8 @@ information, please read our [Security Policy][9].
3131
All interactions in our official communication channels follow our
3232
[Code of Conduct][1].
3333

34+
All contributions are required to conform to our [Open Source Policy][11].
35+
3436
## Bug reports
3537

3638
For reporting bugs, [visit our issue tracker][2] and follow the steps
@@ -213,6 +215,65 @@ into the repository. If you have carefully organized your commits and
213215
believe they should be merged without squashing, please mention it in
214216
a comment.
215217

218+
### Licensing and Compliance Requirements
219+
220+
Please review our [Open Source Policy][11] for complete guidelines on licensing
221+
and compliance. Below is a summary of the key points affecting
222+
**all external contributors**:
223+
224+
- **Accepted Licenses:** Any code contributed must be licensed under the
225+
`Apache-2.0` license.
226+
- **SPDX License Headers:** With the exception of approved test fixture files,
227+
**all new or modified files** in a pull request must include correct SPDX
228+
headers. If you are creating a new file under the `Apache-2.0` license, for
229+
instance, please use:
230+
231+
```elixir
232+
# SPDX-License-Identifier: Apache-2.0
233+
# SPDX-FileCopyrightText: 2021 The Elixir Team
234+
```
235+
236+
- **No Executable Binaries:** Contributions must **not** include any executable
237+
binary files. If you require an exception (for example, certain test artifacts),
238+
please see the policy on how to request approval and document exceptions.
239+
- **Preserving Copyright and License Info:** If you copy code from elsewhere,
240+
ensure that **all original copyright and license notices remain intact**. If
241+
they are missing or incomplete, you must add them.
242+
- **Failure to Comply:** Pull requests that do not meet these licensing and
243+
compliance standards will be rejected or require modifications before merging.
244+
- **Developer Certificate of Origin:** All contributions are subject to the
245+
Developer Certificate of Origin.
246+
247+
```
248+
By making a contribution to this project, I certify that:
249+
250+
(a) The contribution was created in whole or in part by me and I
251+
have the right to submit it under the open source license
252+
indicated in the file; or
253+
254+
(b) The contribution is based upon previous work that, to the
255+
best of my knowledge, is covered under an appropriate open
256+
source license and I have the right under that license to
257+
submit that work with modifications, whether created in whole
258+
or in part by me, under the same open source license (unless
259+
I am permitted to submit under a different license), as
260+
Indicated in the file; or
261+
262+
(c) The contribution was provided directly to me by some other
263+
person who certified (a), (b) or (c) and I have not modified
264+
it.
265+
266+
(d) I understand and agree that this project and the contribution
267+
are public and that a record of the contribution (including
268+
all personal information I submit with it, including my
269+
sign-off) is maintained indefinitely and may be redistributed
270+
consistent with this project or the open source license(s)
271+
involved.
272+
```
273+
274+
See http://developercertificate.org/ for a copy of the Developer Certificate
275+
of Origin license.
276+
216277
## Building documentation
217278

218279
Building the documentation requires that [ExDoc](https://github.com/elixir-lang/ex_doc)
@@ -256,6 +317,7 @@ and `mix` under the `doc` directory. If you are planning to contribute documenta
256317
[8]: https://groups.google.com/group/elixir-lang-ann
257318
[9]: SECURITY.md
258319
[10]: https://groups.google.com/forum/#!searchin/elixir-lang-ann/%5Bsecurity%5D%7Csort:date
320+
[11]: OPEN_SOURCE_POLICY.md
259321
260322
## License
261323

0 commit comments

Comments
 (0)