[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Acceptability of a documentation license for Debian

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

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

> 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>

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: