• Acceptability of a documentation license for Debian

    From Jeffrey H. Johnson@21:1/5 to All on Mon Aug 30 02:30:01 2021
    Greetings,

    I'm contacting the list to inquire regarding the acceptability
    of the following proposed documentation license, as I'd like to
    ensure that it will become be an impediment to having
    documentation licensed under it added to Debian in the future.

    ---

    THE DPS8M DOCUMENTATION LICENSE

    Version 0.9, 29 August 2021

    Copyright © 2019‑2021 The DPS8M Development Team

    All Rights Reserved.

    This documentation was produced by The DPS8M Development Team and other contributors. Any views or conclusions contained in this documentation
    are those of the authors, and must not be interpreted as representing
    official policies, either express or implied, of The DPS8M Development
    Team.

    Redistribution and use in ‘source’ (including, but not limited to, TeX, LaTeX, SGML DocBook, reStructuredText, Markdown, RUNOFF, Lout, etc.)
    and ‘compiled’ forms (including, but not limited to, transformations to other DTDs, conversions to SGML, XHTML, PDF, DjVu, XPS, PostScript, RTF,
    or other formats, etc.), in whole or in part, for any purpose, including commercial applications, with or without modification, in any medium, is
    hereby permitted, without fee or royalty, provided that the following conditions are met:

    1. Redistributions of ‘source
  • From J.B. Nicholson@21:1/5 to Jeffrey H. Johnson on Mon Aug 30 05:20:03 2021
    Jeffrey H. Johnson wrote:
    I'm contacting the list to inquire regarding the acceptability
    of the following proposed documentation license, as I'd like to
    ensure that it will become be an impediment to having
    documentation licensed under it added to Debian in the future.

    The DPS8M license version 0.9 is non-free.

    Redistribution and use in ‘source’ [...] and ‘compiled’ forms [...] in whole or in
    part, for any purpose, including commercial applications, with or without modification, in any medium, is hereby permitted, without fee or royalty, provided
    that the following conditions are met:

    Prohibiting distribution for a fee is non-free is a clear violation of DFSG 1 (per
    https://www.debian.org/social_contract#guidelines). Also, prohibiting distribution
    for a fee while allowing redistribution in "commercial applications" is confusing.

    I suggest considering another license that is clearly free for your documentation.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J.B. Nicholson@21:1/5 to Walter Landry on Mon Aug 30 07:40:02 2021
    On 2021-08-29 11:03 PM, Walter Landry wrote:
    The license looks to me like it is saying that anyone distributing the
    work does not have to pay a fee to the original author. It does not
    prohibit the distributor from imposing fees on end recipients.
    Otherwise, the blurb about 'commercial applications' would be
    contradictory.

    Thanks for the correction. If that's the case then I change my objection
    to:
    - not defining terms clearly,
    - wondering how onerous it is to comply with condition #2

    Condition #2 requires verbatim reproduction of "above text, copyright
    notice, any other notices of legal privilege, this list of conditions,
    and the following disclaimer prominently in the documentation and/or
    other human-readable materials provided with the distribution",
    particularly when documentation is embedded in software.

    Does condition #2 rise to the level of problem akin to what is described
    in https://www.gnu.org/licenses/bsd.html ? That could pose a problem for practical use -- not enough to make the license non-free (thus directly contradicting what I wrote earlier) but enough to make this license a
    nuisance and worth avoiding.

    What does anyone believe that they'd gain from using this license
    instead of some other license that is much more well-understood and
    clearly free?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Francesco Poli@21:1/5 to All on Mon Aug 30 15:20:02 2021
    On Sun, 29 Aug 2021 20:16:57 -0400 Jeffrey H. Johnson wrote:

    Greetings,

    I'm contacting the list to inquire regarding the acceptability
    of the following proposed documentation license, as I'd like to
    ensure that it will become be an impediment to having
    documentation licensed under it added to Debian in the future.

    Hello,
    you seem to be drafting (possibly along with other people) a new
    license that you propose for documentation.

    Even before commenting the details of the license text, I would like to
    express my own personal opinion on the operation itself.
    My personal recommendation is: please, don't.

    License proliferation is harmful, and adding another newly drafted
    license to the already excessively long list of existing licenses
    should be avoided, unless absolutely necessary.
    Writing a good license text, avoiding all the subtle pitfalls that may
    cause unexpected results, is a very hard task: even legal experts may
    spend a very long time and yet come up with a flawed text.
    The use of existing, well-known and well-vetted licenses is highly
    recommended.

    Moreover, you are proposing a license specifically designed to be
    applied to documentation only.
    This is a poor choice, because the boundaries of what is exactly "documentation" are not so well-defined as one might think.
    In my own personal opinion, a good license should applicable to any
    kind of software (in the broad sense of the word, see my [essay] on the
    topic, for more details).

    [essay]: <https://www.inventati.org/frx/essays/softfrdm/whatissoftware.html>


    You are searching for a good simple and permissive license that can be
    applied to documentation.

    My recommendation is: if you are writing documentation for a specific
    program or library, use the same license as the program or library
    itself. This allows anyone to transfer material back and forth between
    the program or library and the documentation without having to ask for additional permissions (for instance: material from the documentation
    may be used to enhance the online help of a program or the comments in
    the source code of a library, and vice-versa).
    In the case of DPS8M, I seem to understand that the majority of the
    code is under the [ICU license], which looks perfectly OK for
    documentation as well (and meets the DFSG).

    [ICU license]: <https://gitlab.com/dps8m/dps8m/-/blob/505ed98481766ac936cf0b5ff8de04abd7547f08/LICENSE.md#dps8m-simulator

    Otherwise, if you are writing general documentation about many
    different programs/libraries or about other topics (science, art, ...),
    a simple permissive license that I would recommend is the [Expat]
    license or the [zlib] license.

    [Expat]: <http://www.jclark.com/xml/copying.txt>
    [zlib]: <https://www.zlib.net/zlib_license.html>

    [...]
    Thank you,

    Thanks to you for asking for advice!
    I hope my reply may be helpful.


    --
    http://www.inventati.org/frx/
    There's not a second to spare! To the laboratory! ..................................................... Francesco Poli .
    GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEygERR5zS79/7gjklPhwn4R9pv/4FAmEs2n0ACgkQPhwn4R9p v/4Gnw/+K5aQU1EhJ5X/fKysUW2VlpWhA2PeZQmEyKOkrJpoFCCMKEgt8hK52IPD F4ssXW2eKH8RBT1KqmBGFZPm+kgZlryVemB9YKF9i08s5sopTyt4/KGZgKeF0LHX qRvM/ZMVVqLeSWzHs2PuUh7nwX/0TO2tvcCL5WhKooqRkX5MXYi4yyxYrr90juRq 7D0ft+I8Hfi3m+o5b9PJoQDwt7fTbCHkPU+ybqCiae9/RJJLwAVKJkvg3Sovv8FX iWABdAHGvBDlCqxDOlzs6wt1CGQIvEHJuqgmzOcR3lxaTnNLRkGTeauxm32jC4pm SfSdHg8EXquZCWKLYt+ajiXBlTkiWWEQeKDkFKRyKIlMEnfoKSyUZ88ZabSb9mP8 JFuNOVn/rm43PpoIGfgkvxbwyw0vuQ8y8AYYaSDBwbuM6CTxcgUT3EQtIjtpoWEf TLqPIwp0PJGH5vciyWuRkF1j0ad3TXY6/P+r/yujL9Wap2iSIeJf4+bqnudABix7 BwsixibTnKabv4Xx+ch9R5mmTH3lW2F5fn3oRMsosW1JPhsJGuH/nI6Ki9Y0O39S YAZg14VqW/dk3cK36Wph3u9VAd2HEetwDWiLh/vE6oG5j5zQiamouEwdEryARtl9 4nsfGHncSCmiHegVrKwXlUwyyYrsIEfg
  • From Jeffrey H. Johnson@21:1/5 to All on Mon Aug 30 20:50:01 2021
    I thank everyone for the feedback,

    Rather than address every individual point of the replies, or propose
    updated text, it might be most helpful to explain the intent. I absolutely
    will take into consideration and agree with comments and concerns
    regarding license proliferation.

    The documentation/work to be produced is additional "book-style" long-form documentation, which will aim to document not only DPS8M but also provide background information on the platform, the instruction set and
    architecture, and the people involved (with the hardware and software,
    both current and historical), so there is a need to alleviate and minimize
    any concerns, founded or not, that potential contributors to the work may
    have. While using the ICU license is an option (and it will in fact be
    used for some of the documentation), for the 'book', it may require
    additional buy-in or result in differing contributions to the final work.

    1. Because of the 'personal' nature of some of the planned materials that
    will be included, it's important for those potential contributors to be
    able to voice their opinions and view of history but not have their
    authorship nor these views and opinions later misattributed or
    misrepresented, while also making clear that those views and opinions of
    the authors are not official policies of the development and documentation team.

    2. The simulator itself will bundle man pages and some documentation as
    well as provide online help within the simulator, which of course will be licensed under the ICU license.

    3. The project is not only a platform simulator, but a distribution/suite
    of programs, which includes utilities and tools -- Auditing the
    distribution for license compatibility and compliance has certainly been a chore and there is still some work to do. For example, we've removed
    and/or completely rewritten some questionable code (such as small amounts
    of code that seem to have come from glibc, or licensed under non-
    commercial terms, or without any clear lineage to all), clarified the
    licenses of other code and contacted the original authors of that code
    when necessary, and fully documented all licenses as we go along (the https://gitlab.com/dps8m/dps8m/-/blob/master/LICENSE.md file) to ensure
    that all contributors receive proper attribution. We've also ensured that scripts and parts of the build system are properly licensed just in case
    (this isn't BSD custom, which I am more familiar with). We don't want the license in the documentation to imply it is the license of the software,
    which in many cases, it will not be.

    4. In documenting the simulator and architecture, we will inevitably end
    up using some Multics source code, which will require reproduction of the Multics historical background and copyright notice - https://opensource.org/licenses/Multics - the proposed documentation
    license is intended to convey similar terms.

    5. As state above, there is concern at the phrasing of "the Software" as
    used in these licenses (such as zlib), when applied strictly to
    documentation. We do not want misunderstandings or confusion that the documentation is the simulator software, bundled utilities that the documentation describes but are differently licensed, etc. I do
    understand there are subtleties as to exactly what is documentation and
    what is not, and the licenses such as zlib further exacerbate this issue
    by making an implied distinction between the documentation and the
    software, for example: "Permission is granted to anyone to use this
    software ..." and later "an acknowledgment in the product documentation
    would be appreciated". This is especially confusing when the
    documentation IS 'the software', and provides room for argument over the resulting compiled documentation output (PDF, etc.).

    6. Originally, the GFDL was discussed, but it is my understanding the the
    GFDL is still controversial within Debian, and I would like to avoid the situation where an optional dps8m-docs package would not be eligible for inclusion, because having the simulator available in Debian is a personal
    goal. There are also other problems with the GFDL regarding DRM
    distribution, etc.

    7. Mostly a concern with GFDL-like license, but we want it to be clear
    that this documentation is not restricted in distribution by medium,
    including DRM'd mediums such as Amazon Kindle or Apple App Store markets.

    8. Licensing the documentation under the same license as the software
    would mean that some parts of the documentation (and different sections of
    the book) would be need to be licensed under at least 1) the ICU License,
    2) the zero-clause BSD license, 3) a two-clause BSD license, 4) a three-
    clause BSD license, 5) a modified MIT license, and possibly parts 6)
    released to the public domain. I would normally agree that having the documentation produced under the same license as the software is
    preferred, but in this case, it seems that would be a nightmare.

    It's not an 'official goal' of the project per se, and we are a way off,
    but as long as I'm doing the legwork, no one is opposed.

    With all that said, I personally find the zlib license to be compatible in
    both spirit and intent to what we are trying to achieve, except for the
    issues noted above.

    There has been some legal consultation in drafting the current license
    text and recommendations followed, but no strict legal requirements are
    imposed upon us (nor me personally), thankfully! Before any final legal
    review is requested, it's more important that the license is acceptable to
    the community (Debian, Fedora) than it is to an attorney. Of course, I'd
    like it even better to not have to have something new reviewed.

    Finally, if need be, Debian could not ship the future -docs package, but
    that would be the worst outcome.

    I appreciate the kind feedback from Debian volunteers.

    --
    Jeffrey H. Johnson
    trnsz@pobox.com

    Otherwise, if you are writing general documentation about many
    different programs/libraries or about other topics (science, art, ...),
    a simple permissive license that I would recommend is the [Expat]
    license or the [zlib] license.

    [Expat]: <http://www.jclark.com/xml/copying.txt>
    [zlib]: <https://www.zlib.net/zlib_license.html>

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABAgAdFiEEr61rFbeSfDeAGxoN7byz6wI7x+0FAmEtJtYACgkQ7byz6wI7 x+3pcw/9HJyIxJHkgXgDdBRmsXvknBPnpsBScoKKByLMlHDAlY1RWOD4yPYOmKsa TyQr6w0JrdEQODvLaJMqkfbOqb6CLQlW2XrEFKW6pe3dGi/VAiu2dTnGrme2EhXv d5NLBXA8Jbjdk2v1oP/86Aette/wMq3NZ4xd6WAMrflwWWJbWaabO91ClmuPRZuz 8ipPcF4IvSFMf/3ZSjACROMNZWlyogZcEEDA8PjEpWnr9wD9qivvEcollg37fAzq Kq12cwZVVpdYsKtMHEs51u1qzd/M0Ws5XuVneqaXxnqk2NtCP5WYgfaSuBzyXS2U JCiCDT1VwR+MxgsVicbVb5SVqTsmZC8YlwezESD0ZBextiAR3+BNdBRbP6OChPX4 9v7F88fMst8XemBHgZjSZ0DMANV04qQMxnuFbdtukbzmOkeDJCn1Fyuox18pJSVm CaQ8tU2TjGX6/5zKmbM9ke7unhx78xhSwW1HW+P5ab3BRiqAzKO6S3vOKDVowTQD
  • From Tobias Frost@21:1/5 to All on Tue Aug 31 08:30:02 2021
    On Mon, Aug 30, 2021 at 02:43:34PM -0400, Jeffrey H. Johnson wrote:

    (IANAL, IANFTPM (I am not ftp master), etc.)

    I hope you can really find a way to use a standard license. License profiliration
    is really becoming harmful to FOSS.

    ENOTIME for a complete reply to your mail, but two remarks:

    (...)

    5. As state above, there is concern at the phrasing of "the Software" as
    used in these licenses (such as zlib), when applied strictly to documentation. We do not want misunderstandings or confusion that the documentation is the simulator software, bundled utilities that the documentation describes but are differently licensed, etc. I do
    understand there are subtleties as to exactly what is documentation and
    what is not, and the licenses such as zlib further exacerbate this issue
    by making an implied distinction between the documentation and the
    software, for example: "Permission is granted to anyone to use this
    software ..." and later "an acknowledgment in the product documentation
    would be appreciated". This is especially confusing when the
    documentation IS 'the software', and provides room for argument over the resulting compiled documentation output (PDF, etc.).

    Regarding Documentation and Software.
    I've put some FreeCAD files under the GPL and had the same concern that some work / 3d model might not be covered. I've solved this for me by writing "For the avoidance of doubt, "program" can be replaced with "work" in the license grant above." below the GPL boilerplate in the README. Dont know if that
    is legally watertight, but in conveys what I want to archieve.

    6. Originally, the GFDL was discussed, but it is my understanding the the GFDL is still controversial within Debian, and I would like to avoid the situation where an optional dps8m-docs package would not be eligible for inclusion, because having the simulator available in Debian is a personal goal. There are also other problems with the GFDL regarding DRM distribution, etc.

    nope, GFDL and DFSG is settled.
    https://wiki.debian.org/DFSGLicenses#Exception
    As long as there are no invariant sections GFDL is acceptable.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Francesco Poli@21:1/5 to All on Tue Aug 31 16:00:01 2021
    On Tue, 31 Aug 2021 08:28:45 +0200 Tobias Frost wrote:

    On Mon, Aug 30, 2021 at 02:43:34PM -0400, Jeffrey H. Johnson wrote:
    [...]
    5. As state above, there is concern at the phrasing of "the Software" as used in these licenses (such as zlib), when applied strictly to documentation. We do not want misunderstandings or confusion that the documentation is the simulator software, bundled utilities that the documentation describes but are differently licensed, etc. I do
    understand there are subtleties as to exactly what is documentation and what is not, and the licenses such as zlib further exacerbate this issue
    by making an implied distinction between the documentation and the software, for example: "Permission is granted to anyone to use this software ..." and later "an acknowledgment in the product documentation would be appreciated". This is especially confusing when the
    documentation IS 'the software', and provides room for argument over the resulting compiled documentation output (PDF, etc.).

    Regarding Documentation and Software.
    I've put some FreeCAD files under the GPL and had the same concern that some work / 3d model might not be covered. I've solved this for me by writing "For
    the avoidance of doubt, "program" can be replaced with "work" in the license grant above." below the GPL boilerplate in the README. Dont know if that
    is legally watertight, but in conveys what I want to archieve.

    I don't think that's really needed, since the GNU GPL v2 already
    explicitly states in its very text:

    [...]
    | 0. This License applies to any program or other work which contains
    ^^^^^^^^^^^^^
    | a notice placed by the copyright holder saying it may be distributed
    | under the terms of this General Public License. The "Program", below,
    | refers to any such program or work
    ^^^^^^^
    [...]

    Similarly the GNU GPL v3 states:

    [...]
    | "The Program" refers to any copyrightable work licensed under this
    ^^^^^^^^^^^^^^^^^^^^^^
    | License.
    [...]

    In other words, when the GPL says "Program", it means any work to which
    the license is applied, not necessarily an executable program.


    Anyway, since many people tend to not read the license text, or not do
    so carefully enough, I understand the reason why you felt the need to
    add the above clarification in the README...

    Oh, and by the way, thanks a lot for licensing 3d models under the GNU
    GPL! I wish more people chose really DFSG-free terms (such as GPL or
    Expat or zlib or 3-clause BSD) for 3d models!


    Back to Jeffrey's concerns, though.

    I do not think that the zlib license text is especially confusing with
    respect to the software / program / documentation terminology.

    It never says "program", always "software" (which may well be
    interpreted in its broadest sense, in my opinion).
    The only clause that talks about "documentation" is the first one,
    where it talks about the documentation for a potential "product" that
    uses the software, not about documentation for the software itself.
    And please note that the only part that talks about "documentation" is
    not legally binding, it's just a polite request (hence, in case it
    turns out to have an unclear meaning, the licensee can always choose to
    ignore the request...).


    6. Originally, the GFDL was discussed, but it is my understanding the the GFDL is still controversial within Debian, and I would like to avoid the situation where an optional dps8m-docs package would not be eligible for inclusion, because having the simulator available in Debian is a personal goal. There are also other problems with the GFDL regarding DRM distribution, etc.

    nope, GFDL and DFSG is settled. https://wiki.debian.org/DFSGLicenses#Exception
    As long as there are no invariant sections GFDL is acceptable.

    Please do not remind me of one of the first big disappointments I had
    with the Debian Project...
    I personally strongly disagree with the decision made with GR-2006-001.

    Even so, the [winning option], despite (sadly) choosing to accept invariant-less GFDL'd documents in Debian main, ended with the
    following consideration:

    [...]
    | 3. Despite the above, GFDL'd documentation is still not free of
    | trouble, even for works with no invariant sections: as an example, it
    | is incompatible with the major free software licenses, which means
    | that GFDL'd text can't be incorporated into free programs.
    |
    | For this reason, we encourage documentation authors to license their
    | works (or dual-license, together with the GFDL) under the same terms
    | as the software they refer to, or any of the traditional free
    | software licenses like the GPL or the BSD license.

    [winning option]: <https://www.debian.org/vote/2006/vote_001#amendmenttexta>




    --
    http://www.inventati.org/frx/
    There's not a second to spare! To the laboratory! ..................................................... Francesco Poli .
    GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEygERR5zS79/7gjklPhwn4R9pv/4FAmEuNTAACgkQPhwn4R9p v/7a0Q/9G94G/zeM0F+e1oDLTvXZCvRIDknxEn2hWzuN3Q7jr4Xu6ESIok3r3cfR UMe4IpNVnsVoFeHvpVUN6YdUEAHUVn2pqw251tNcJLTE8LSNnxLrJELsXi+CAQr+ 5d/fbN7GM52pUQ5q5+GDHfxACzPTRom9OO5yHoZ8MZWFFAAuiG8q5kC4RNNnknh0 7EiE6Mua+5mNXom9/R1lKnw3rrV4FRSwBqSnbJouez2KdXd/Vk8vhM5Vxitfvh/R EQdHK/EXS+HMEesO9W2K8ssUXJ7BJ5h6uM3Jw94hAbYHCLOTSJxyZ4yDxH9Bqb7E 32aCIuW1GGRoojHRqx9bYXer724vofaCknfkRviJO1FrqCdSDrAqwoIqiqUZW1zs mYfPDpG0cNiFM2yXGrZwSGnq6Vmx7+YZ+ZZTUXYMgHp91G9/1F7Bv9Vi+PxO/KJK rdmoZeKjUkSHvWomSQi0I1qN4vfCp88jGjdgXx8IB8VOYQ0jxLhrf12dNY972i35 y6SmH9+tQ14mKhG0OsBI8VxSJdSO0pBq+y5z3ZM3N7rDeA9cSYvPGgQrM3nUSv3Z GLXL19BxFoSXcuAyfdu21y7PjzAXdwstSnzS0z+uytErpWNrmOCpqoS16bZZ/OYZ fHbUcq0VLlkwUo/ap76s0mTm3RUQUOhn