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>
Attachment:
signature.asc
Description: This is a digitally signed message part