Add changelog entry, and FAQ for "altered versions" marking
Marco Ricci commited on 2025-01-07 15:35:45
Zeige 4 geänderte Dateien mit 43 Einfügungen und 1 Löschungen.
- docs/changelog.d/20250107_145357_the-13th-letter_2025_and_zlib_license.md 0000000..b89a1c5
- docs/explanation/faq-altered-versions.md 0000000..8c4254c
- docs/explanation/index.md 0000000..a47a238
- mkdocs.yml 633036a..9ab4aae
| ... | ... |
@@ -0,0 +1,10 @@ |
| 1 |
+### Changed |
|
| 2 |
+ |
|
| 3 |
+ - `derivepassphrase` changed its license from [MIT][] to [zlib/libpng][]. |
|
| 4 |
+ This should only make a difference to people redistributing altered |
|
| 5 |
+ versions of `derivepassphrase`; the basic freedoms, and the |
|
| 6 |
+ combinability of `derivepassphrase` with other software should be |
|
| 7 |
+ unaffected. |
|
| 8 |
+ |
|
| 9 |
+[MIT]: https://spdx.org/licenses/MIT.html |
|
| 10 |
+[zlib/libpng]: https://spdx.org/licenses/Zlib.html |
| ... | ... |
@@ -0,0 +1,22 @@ |
| 1 |
+# How to comply with the "altered versions" clause of the license |
|
| 2 |
+ |
|
| 3 |
+**Short answer:** change the package name and/or change the version number to include a [PEP 440][] "local version identifier". |
|
| 4 |
+If `derivepassphrase` ever rebrands, this applies to rebranded names too. |
|
| 5 |
+We try not to clash with anyone else, and will yank our offending releases if we do. |
|
| 6 |
+ |
|
| 7 |
+**Long answer:** We, upstream `derivepassphrase`, reserve the name `derivepassphrase` and certain version numbers for ourselves. |
|
| 8 |
+Specifically, our version numbers adhere to [PEP 440][] (or newer revisions) and generally do not include a "local version identifier". |
|
| 9 |
+To mark an altered version, we thus recommend that you change the software package name `derivepassphrase`, or use a version number with a local version identifier. |
|
| 10 |
+If we (upstream) decide to use a local version identifier, we will avoid all clashing local version identifiers we are aware of, and if informed of a clashing local version identifier after our release, will yank our offending version(s). |
|
| 11 |
+ |
|
| 12 |
+Should we (upstream) change the package name, we shall apply the same guidelines and checks concerning local version identifiers to the new package name. |
|
| 13 |
+A change of package name does *not* by itself imply permission to use the old package name for future releases of altered versions without marking them. |
|
| 14 |
+ |
|
| 15 |
+--- |
|
| 16 |
+ |
|
| 17 |
+See also [the zlib project's take on how to mark altered versions][ZLIB_FAQ]. |
|
| 18 |
+Like them, we recommend keeping our upstream Changelog (up to the point where you introduced modifications) and describing your modifications both there and in the README, in the appropriate level of detail. |
|
| 19 |
+We also request (but do not require) that you provide clear instructions in the README (and potentially other suitable places) on where and how to report problems that stem from your modifications, not from the upstream software package. |
|
| 20 |
+ |
|
| 21 |
+[PEP 440]: https://peps.python.org/pep-0440/ |
|
| 22 |
+[ZLIB_FAQ]: https://github.com/madler/zlib/blob/v1.3.1/FAQ "see question #24" |
| ... | ... |
@@ -110,7 +110,9 @@ nav: |
| 110 | 110 |
- Submodule vault: reference/derivepassphrase.vault.md |
| 111 | 111 |
- Technical prerequisites: |
| 112 | 112 |
- 'Using derivepassphrase vault with an SSH key': reference/prerequisites-ssh-key.md |
| 113 |
- #- Design & Background: explanation.md |
|
| 113 |
+ - Design & Background: |
|
| 114 |
+ - explanation/index.md |
|
| 115 |
+ - '"altered versions" license requirement': explanation/faq-altered-versions.md |
|
| 114 | 116 |
- Changelog: changelog.md |
| 115 | 117 |
exclude_docs: | |
| 116 | 118 |
changelog.d |
| 117 | 119 |