Skip to content

Commit 691a23f

Browse files
shanecoughlanshanecoughlan
committed
Update REUSE.software-1.0.md
Fixed REUSE 1.0 MarkDown formatting
1 parent c2ecef8 commit 691a23f

File tree

1 file changed

+106
-203
lines changed

1 file changed

+106
-203
lines changed

‎General-Compliance-Support-Material/Reusing-Software/en/REUSE.software-1.0.md

Lines changed: 106 additions & 203 deletions
Original file line numberDiff line numberDiff line change
@@ -2,228 +2,131 @@
22

33
This document is based on reuse.software, a project launched by FSFE, and redistributed under CC-0 with their kind permission.
44

5-
<!--START_HTML-->
6-
7-
<h2>Summary</h2>
8-
9-
<table>
10-
<tr>
11-
<td>
12-
<img alt="1. " src="/img/one_sm.png" />
13-
</td>
14-
<td>Provide the exact text of each license used, in verbatim form, without removing any existing license texts. <a href="#one">[read more]</a>
15-
</td>
16-
</tr>
17-
<tr>
18-
<td>
19-
<img alt="2. " src="/img/two_sm.png" />
20-
</td>
21-
<td>
22-
Include a copyright notice and license in each file, with a consistent style, with a reference to the license text and an appropriate SPDX License Identifier. <a href="#two">[read more]</a>
23-
</td>
24-
</tr>
25-
<tr>
26-
<td>
27-
<img alt="3. " src="/img/three_sm.png" />
28-
</td>
29-
<td>
30-
Provide an inventory for included software, but only if you can generate it automatically! <a href="#three">[read more]</a>
31-
</td>
32-
</tr>
33-
</table>
34-
35-
<div style="margin: 6em;"></div>
36-
<!--END_HTML-->
5+
## Summary
6+
7+
| | Provide the exact text of each license used, in verbatim form, without removing any existing license texts. [[read more]](#one) |
8+
| --- | --- |
9+
| | Include a copyright notice and license in each file, with a consistent style, with a reference to the license text and an appropriate SPDX License Identifier. [[read more]](#two) |
10+
| | Provide an inventory for included software, but only if you can generate it automatically! [[read more]](#three) |
3711

3812
# Best practices
3913

40-
<a name="one"></a>
4114
## 1. Provide the exact text of each license used
42-
Free and open source software licenses are standardised and have standard
43-
texts. Regardless of which license you use, you should include the
44-
license text in your project. You should also include the license text of
45-
any code which may be under a different license, and it's important you
46-
do not change the license text on other software you include.
47-
48-
If the license you use is included in the SPDX License List[^1], you
49-
should download and copy the text representation of the license
50-
directly from the SPDX repository[^2]. Doing so ensures that unless you modify
51-
the license text, the checksum of the license file will be identical across
52-
all projects using the same license.
53-
54-
If your project only includes code licensed under a single license, you
55-
may provide the text of this license in a file in the top level directory
56-
of your repository with the name "LICENSE" (you may attach some suffix
57-
to the filename as well, such as LICENSE.md, if relevant).
58-
59-
Since many projects include code under different licenses, it's often not
60-
feasible to include all licenses in the top level, in which case you should
61-
create a directory at the top level called "LICENSES" within which you
62-
include the license text of each license used.
63-
64-
You must include all licenses which are used in your project, and you must
65-
never change any license texts even if they are very similar to existing ones.
66-
Some licenses, like the BSD 2 Clause license, must be
67-
adapted to include the name of the copyright holder in the license
68-
text. Your project may end up including multiple versions of the same
69-
BSD 2 Clause license because some parts may be written by Alice and others
70-
by Bob, resulting in two different license files, even if the only
71-
difference is the copyright holder.
72-
73-
This is how your source code tree can end up looking regarding the license
74-
files included:
75-
76-
~~~~~~~
77-
LICENSES/
78-
GPL-2.0.txt
79-
BSD-2-Clause_Alice.txt
80-
BSD-2-Clause_Bob.txt
81-
~~~~~~~
8215

83-
Keep in mind:
16+
Free and open source software licenses are standardised and have standard texts. Regardless of which license you use, you should include the license text in your project. You should also include the license text of any code which may be under a different license, and it's important you do not change the license text on other software you include.
17+
18+
If the license you use is included in the SPDX License List[^1](https://spdx.org/licenses/), you should download and copy the text representation of the license directly from the SPDX repository[^2](https://github.com/spdx/license-list). Doing so ensures that unless you modify the license text, the checksum of the license file will be identical across all projects using the same license.
19+
20+
If your project only includes code licensed under a single license, you may provide the text of this license in a file in the top level directory of your repository with the name "LICENSE" (you may attach some suffix to the filename as well, such as LICENSE.md, if relevant).
21+
22+
Since many projects include code under different licenses, it's often not feasible to include all licenses in the top level, in which case you should create a directory at the top level called "LICENSES" within which you include the license text of each license used.
23+
24+
You must include all licenses which are used in your project, and you must never change any license texts even if they are very similar to existing ones. Some licenses, like the BSD 2 Clause license, must be adapted to include the name of the copyright holder in the license text. Your project may end up including multiple versions of the same BSD 2 Clause license because some parts may be written by Alice and others by Bob, resulting in two different license files, even if the only difference is the copyright holder.
8425

85-
* Don't change any license texts, use the verbatim form of the license text
86-
* Don't remove any license texts, include the license texts of all software
87-
* Keep the filename of the licenses consistent, so you can refer to it
88-
from the source code files (see the following practice)
26+
This is how your source code tree can end up looking regarding the license files included:
27+
28+
LICENSES/
29+
30+
GPL-2.0.txt
31+
32+
BSD-2-Clause\_Alice.txt
33+
34+
BSD-2-Clause\_Bob.txt
35+
36+
Keep in mind:
8937

90-
[^1]: https://spdx.org/licenses/
91-
[^2]: https://github.com/spdx/license-list
38+
- Don't change any license texts, use the verbatim form of the license text
39+
- Don't remove any license texts, include the license texts of all software
40+
- Keep the filename of the licenses consistent, so you can refer to it from the source code files (see the following practice)
9241

93-
<a name="two"></a>
9442
## 2. Include a copyright notice and license in each file
95-
You should ensure all files in your project have a license header, and
96-
that all license headers files have the same format. Even if your project has a
97-
license header which looks different from other projects, it helps to have
98-
a consistent style to the header. It's important you do not remove
99-
information in existing headers, though.
100-
101-
Source code files are often reused across multiple projects, taken from their
102-
origin and repurposed, or otherwise end up in repositories where they are
103-
separate from its origin. Each file should, therefore,
104-
have enough information in itself to convey copyright
105-
information.
106-
107-
You may record information about copyright by relying on the underlying
108-
version control system you're using, but special care must be taken if you
109-
do. Keep in mind that version control systems typically record authorship,
110-
not copyright. When using metadata in a version control system, you may end up having
111-
more accurate information, but you increase the risk of the information being
112-
separated from the source code.
113-
114-
For a project using the version control system to convey information about
115-
copyright, you must:
116-
117-
* make sure the version control system is publicly accessible and take
118-
steps[^3] to ensure it will remain so,
119-
* provide a link back to the original file in version control from each header,
120-
* ensure that if someone copies the source repository without version
121-
control system metadata (such as if they make a tar-file of it),
122-
then the version control system metadata relevant for determining
123-
copyright must still be included,
124-
for example in the form of a bill of material (see later), an
125-
automatically generated log file or similar,
126-
* make sure the commit metadata reflect the actual copyright
127-
(this is particularly important if a project accepts code contributed
128-
through mailing lists, bug trackers, or similar, where the original
129-
copyright holder is not the one pushing code to version control, or
130-
where the copyright is held by an organisation rather than the author.)
43+
44+
You should ensure all files in your project have a license header, and that all license headers files have the same format. Even if your project has a license header which looks different from other projects, it helps to have a consistent style to the header. It's important you do not remove information in existing headers, though.
45+
46+
Source code files are often reused across multiple projects, taken from their origin and repurposed, or otherwise end up in repositories where they are separate from its origin. Each file should, therefore, have enough information in itself to convey copyright information.
47+
48+
You may record information about copyright by relying on the underlying version control system you're using, but special care must be taken if you do. Keep in mind that version control systems typically record authorship, not copyright. When using metadata in a version control system, you may end up having more accurate information, but you increase the risk of the information being separated from the source code.
49+
50+
For a project using the version control system to convey information about copyright, you must:
51+
52+
- make sure the version control system is publicly accessible and take steps[^3] to ensure it will remain so,
53+
- provide a link back to the original file in version control from each header,
54+
- ensure that if someone copies the source repository without version control system metadata (such as if they make a tar-file of it), then the version control system metadata relevant for determining copyright must still be included, for example in the form of a bill of material (see later), an automatically generated log file or similar,
55+
- make sure the commit metadata reflect the actual copyright (this is particularly important if a project accepts code contributed through mailing lists, bug trackers, or similar, where the original copyright holder is not the one pushing code to version control, or where the copyright is held by an organisation rather than the author.)
13156

13257
An appropriate header could be:
13358

134-
~~~~~~~
135-
/*
136-
* This file is part of project X. It's copyrighted by the contributors
137-
* recorded in the version control history of the file, available from
138-
* its original location http://git.example.com/X/filename.c
139-
*
140-
* SPDX-License-Identifier: BSD-2-Clause
141-
* License-Filename: LICENSE/BSD-2-Clause_Charlie.txt
142-
*/
143-
~~~~~~~
144-
145-
If the project is not using a version control system to convey copyright
146-
information, the same information should be included in the source
147-
code file. Notices should have a consistent format and be sorted
148-
by year. They should list the actual copyright holder, which may be
149-
an organisation rather than the author.
150-
151-
~~~~~~~
152-
/*
153-
* Copyright (c) 2017 Alice Commit <[email protected]>
154-
* Copyright (c) 2009-2016 Bob Denver <[email protected]>
155-
* Copyright (c) 2007 Company Example <[email protected]>
156-
*
157-
* SPDX-License-Identifier: BSD-2-Clause
158-
* License-Filename: LICENSE/BSD-2-Clause_Charlie.txt
159-
*/
160-
~~~~~~~
161-
162-
The "License-Filename" tag shall be a persistent URL or a filename in
163-
the repository where the actual license text is available. This is more
164-
accurate than the SPDX license identifier and ensures the full license
165-
text is always referenced from the individual source file. The tag can
166-
be repeated if multiple license files are relevant.
167-
168-
You should include information about your project's practices in the
169-
README or similar file.
170-
171-
If your project includes binaries or source code files in which
172-
comments can not be placed, you should provide them separately. We
173-
recommend one of two ways:
174-
175-
* If you have files with different copyright notices and licenses, you should, for each file named FILENAME, include the text file "FILENAME.license" which includes a copyright header according to the format you customarily use for headers.
176-
* If you have many such files, but each have the same copyright notice and license, you may instead use the [DEP-5/copyright](https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) file format, and place a single copyright file documenting those files.
177-
178-
If you wish to be explicit about the license of an output file, which does
179-
not exist in the repository but which will be created at build time, you
180-
may include a .license file without the corresponding binary file.
59+
/\*
60+
61+
\* This file is part of project X. It's copyrighted by the contributors
62+
63+
\* recorded in the version control history of the file, available from
64+
65+
\* its original location http://git.example.com/X/filename.c
66+
67+
\*
68+
69+
\* SPDX-License-Identifier: BSD-2-Clause
70+
71+
\* License-Filename: LICENSE/BSD-2-Clause\_Charlie.txt
72+
73+
\*/
74+
75+
If the project is not using a version control system to convey copyright information, the same information should be included in the source code file. Notices should have a consistent format and be sorted by year. They should list the actual copyright holder, which may be an organisation rather than the author.
76+
77+
/\*
78+
79+
\* Copyright (c) 2017 Alice Commit \<[email protected]\>
80+
81+
\* Copyright (c) 2009-2016 Bob Denver \<[email protected]\>
82+
83+
\* Copyright (c) 2007 Company Example \<[email protected]\>
84+
85+
\*
86+
87+
\* SPDX-License-Identifier: BSD-2-Clause
88+
89+
\* License-Filename: LICENSE/BSD-2-Clause\_Charlie.txt
90+
91+
\*/
92+
93+
The "License-Filename" tag shall be a persistent URL or a filename in the repository where the actual license text is available. This is more accurate than the SPDX license identifier and ensures the full license text is always referenced from the individual source file. The tag can be repeated if multiple license files are relevant.
94+
95+
You should include information about your project's practices in the README or similar file.
96+
97+
If your project includes binaries or source code files in which comments can not be placed, you should provide them separately. We recommend one of two ways:
98+
99+
- If you have files with different copyright notices and licenses, you should, for each file named FILENAME, include the text file "FILENAME.license" which includes a copyright header according to the format you customarily use for headers.
100+
- If you have many such files, but each have the same copyright notice and license, you may instead use the [DEP-5/copyright](https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) file format, and place a single copyright file documenting those files.
101+
102+
If you wish to be explicit about the license of an output file, which does not exist in the repository but which will be created at build time, you may include a .license file without the corresponding binary file.
181103

182104
Keep in mind:
183105

184-
* Use a consistent style of your headers throughout the project
185-
* Don't remove existing headers, but only add to them
186-
* Do consider using version control systems to keep a record of copyright holders
187-
* Do keep your version control system public if you use it
188-
* Make references to the license text and the SPDX identifier from each source code file
189-
* Include license and copyright information also for files which can not include a proper header, either in a separate .license file, or using the DEP-5/copyright specification.
106+
- Use a consistent style of your headers throughout the project
107+
- Don't remove existing headers, but only add to them
108+
- Do consider using version control systems to keep a record of copyright holders
109+
- Do keep your version control system public if you use it
110+
- Make references to the license text and the SPDX identifier from each source code file
111+
- Include license and copyright information also for files which can not include a proper header, either in a separate .license file, or using the DEP-5/copyright specification.
190112

191113
[^3]: Establish project governance committed to public access, vet material added to project to protect against vulnerability to takedown, only include material under a free and open source license so it can be copied and archived freely and ensure project is archived by institutions dedicated to long-term preservation of software code, eg. Software Heritage.
192114

193-
194-
<a name="three"></a>
195115
## 3. Provide an inventory for included software
196-
Aside from the license files included in the project, and the file level
197-
copyright information, you may include a bill of material for your project,
198-
but you should only do so if this is generated automatically.
199-
200-
A bill of material can be very complicated and lengthy, making it difficult to
201-
maintain. If you do not generate it automatically, it's very likely someone
202-
will forget to update it when making changes. In these cases, it's best not
203-
to have a bill of material, but to rely only on the information coupled
204-
with the source code files.
205-
206-
If you do have a way of automatically creating a bill of material, and if
207-
you choose to do so, you should generate it automatically from
208-
the most reliable information you have about each file in your project.
209-
This includes copyright information kept in version control systems and
210-
licenses on files which include a standard header, or which includes
211-
the header in a separate license file.
212-
213-
You may also choose to include in the bill of material your output files
214-
generated when compiling the project, such that you can signal through the
215-
bill of material, which license is relevant for the output files depending
216-
on the included source code.
217-
218-
The bill of material should be conformant to the SPDX specification and
219-
included in a file in the top level directory of your repository called
220-
"LICENSE.spdx".
221116

222-
Keep in mind:
117+
Aside from the license files included in the project, and the file level copyright information, you may include a bill of material for your project, but you should only do so if this is generated automatically.
223118

224-
* Don't create a bill of material if you can't generate it automatically
225-
* If you generate one automatically, it's helpful to include one
226-
* Make your bill of material conformant to the SPDX specification
227-
* It doesn't hurt to run your project through ScanCode or FOSSology, to make sure these tools can parse and understand your project's licensing.
119+
A bill of material can be very complicated and lengthy, making it difficult to maintain. If you do not generate it automatically, it's very likely someone will forget to update it when making changes. In these cases, it's best not to have a bill of material, but to rely only on the information coupled with the source code files.
120+
121+
If you do have a way of automatically creating a bill of material, and if you choose to do so, you should generate it automatically from the most reliable information you have about each file in your project. This includes copyright information kept in version control systems and licenses on files which include a standard header, or which includes the header in a separate license file.
122+
123+
You may also choose to include in the bill of material your output files generated when compiling the project, such that you can signal through the bill of material, which license is relevant for the output files depending on the included source code.
124+
125+
The bill of material should be conformant to the SPDX specification and included in a file in the top level directory of your repository called "LICENSE.spdx".
126+
127+
Keep in mind:
228128

229-
<br style="margin: 10em;" />
129+
- Don't create a bill of material if you can't generate it automatically
130+
- If you generate one automatically, it's helpful to include one
131+
- Make your bill of material conformant to the SPDX specification
132+
- It doesn't hurt to run your project through ScanCode or FOSSology, to make sure these tools can parse and understand your project's licensing.

0 commit comments

Comments
 (0)