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

[Xen-devel] [RFC] Documentation formats, licenses and file system structure


  • To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Lars Kurth <lars.kurth@xxxxxxxxxx>
  • Date: Thu, 10 Oct 2019 12:34:33 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=lars.kurth@xxxxxxxxxx; spf=Pass smtp.mailfrom=lars.kurth@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, Committers <committers@xxxxxxxxxxxxxx>
  • Delivery-date: Thu, 10 Oct 2019 12:34:50 +0000
  • Ironport-sdr: btZQbtwf0h1Qx4dI7/FQDFn1vg+rlrSj9qFWQDQJel6GaVr68EI8Tnos8i5mxqwSyS02hGBA2S GI/k9iO1teXJ5IaAVdyl9T9ul78y1EENi5EG1XFm/fSElZYkWJcxUOINGDTYMpPPx4RbQaPAr9 Q2Z22Em14+G9UovUPbSqzdcDUEC0q9cw2RDc4bx6xqx9VozXFt0whwuKfoOkp9dpykaBSSnZPY YuNpLuLAH6Dz0NBbmEAOSr3ePathWcBGjnzJDvpu4eGkPyonBgOi0DeNRM/kgaHAhBEenFNYRS HFI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVf2cRdQE5+PIufEarnRjQ6zCVfw==
  • Thread-topic: [RFC] Documentation formats, licenses and file system structure

Hi all,

following on from a discussion on IRC and on various other places, I think we 
need to try and rationalize how we handle documentation.

What we have now and what we may get in future
* http://xenbits.xen.org/docs/unstable/ (GPL-2)
* http://xenbits.xen.org/docs/sphinx-unstable-staging/ (CC-BY-4)
* Additional API documentation (with a view to enabling safety) 
* Any future documentation related to safety (requirements, designs, test 
cases, tracability)

Desired licenses
* There is a desire to keep 
http://xenbits.xen.org/docs/sphinx-unstable-staging/ CC-BY-4 only
* There is a desire to publish future documentation related to safety as CC-BY-4

Existing formats and licenses
* Hypercall ABI Documentation generated from Xen public headers
Format: kerndoc
License: typically BSD-3-Clause (documentation is generated from public headers)
* docs/designs, docs/features, docs/specs
Formats: primarily pandoc, with some files md
License: GPL-2
* docs/processs - covers internal processes
Formats: txt, with some pandoc
License: GPL-2
* docs/figs
Formats: misc
License: GPL-2
* docs/misc
Formats: txt, with some large number of pandoc, some other docs
License: GPL-2
* docs/man
Formats: pod
License: GPL-2
* Sphinx docs: docs, docs/guest-guide, docs/hypervisor-guide
Formats: rst
License: CC-BY-4

* Wiki: 
Formats: mediawiki markdown
License: CC-BY-SA-3 which has an automatic update to CC-BY-SA-4
(c) of Wiki contributions are kept by the authors

This means that the 3 most common file formats in use are
* pod
* pandoc (with some md) - these are essentially identical
* txt for legacy and old stuff
* rst

License compatibility
* GPL-2 and CC-BY-4 are compatible, but mixing means that the complete docset 
is GPL-2
* GPL-2 and BSD-3-Clause are compatible, but mixing means that the complete 
docset is GPL-2
* BSD-3-Clause and CC-BY-4 I am not 100% sure, but should not be an issue
* CC-BY-SA-4 is only one way compatible with GPLv3 (affecting content on the 
wiki)

The first question is whether we should convert pod to rst
* https://metacpan.org/pod/pod2rst provides a conversion tool
* man pages can be generated by rst2man
Thus, technically this should be easy and should make contributions to docs/man 
easier
If we do this, we should add a CONTRIBUTING file, clarifying the license in 
this directory

There are a set of related questions on what we would eventually merge into the 
sphinx
docset. I believe there is agreement that most of what is in docs today is not 
really
suitable, however there are a few possible exceptions
* man pages - with a variety of different contributors from different orgs. 
Changing license would be hard 
* API docs generated from PUBLIC headers - changing license would be 
impossible, but would be BSD-3-Clause
* Some wiki content (e.g. 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches and friends) 
   More than 95% of changes were from Citrix staff, so we could convert to 
CC-BY-4
   Most non-Citrix changes are one-line changes and could be covered by fair use
* Possibly stuff such as 
https://xenbits.xen.org/docs/unstable/support-matrix.html (which is currently 
GPL-2,
   but we could relicense to say GPL-2 and CC-BY-4 if we had to)
The implication is that the sphinx docs would not be fully CC-BY-4, but the 
bulk of the pages would be

* Would we ever include API docs generated from GPLv2 code? E.g. for safety 
use-cases?
@Stefano, @Artem: I guess this one is for you. 
I suppose if we would have a similar issue for a safety manual
I am also assuming we would want to use sphinx docs and rst to generate a 
future safety manual

Other pages in docs that may be useful for the sphinx docs should essentially 
be re-written, 
so we would be fine from a licensing perspective. That means that over time, we 
could get rid of 
pandoc and text files in docs/misc, docs/designs, docs/features, docs/specs 
which
have not really built a lot of traction.

Related to this is the general question, whether we would ever copy code from 
source to docs
and vice versa and to which degree. This is an unknown to me: I think in 
practice we have not seen
much or even any of this in the past.

On licensing, we should try and make the docs directory clean, e.g.
* We should set the default to CC-BY-4 (e.g. through a contributing file in 
docs)
* And specifically use GPL-2 for directories such as docs/misc, docs/man, ...

In any case, this seems all a little bit of a mess at the moment and I think we 
need to
agree on a foundation to get us to a better state. This mail is a start and 
intends to gather
input and will eventually lead to a more concrete proposal.

If I have missed anything, feel free to add

Best Regards
Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.