On 2024-10-24 18:06, Krzysztof Siewicz via RT wrote:
On Thu Oct 24 00:58:29 2024, jing@jing.rocks wrote:I didn't want to reply until we have a RT ticket number for this thread,so that the licensing team won't need to merge tickets; here we go.On 2024-10-12 12:16, Richard Stallman wrote: > > 2. Should we change this policy? That question is harder. > From what you've said > > We already have many gnu and non-gnu groups in savannah > that use the same license for code and docs; and a documentation > licensed under GPL is certainly libre, > > there are already many packages that use a code license for > the documentation. (How many are there? How many of them > are GNU packages?) I’ll defer this to Bob or corwin
Update: I surveyed about 25% of all gnu packages, here is what I found:Some packages have no (explicit) license on documentations, there is no copy of FDL or mention of FDL. A few packages use the same license (GPL) for code and docs. Skipping packages that have no documentation at all.
Mailman, Mailman3 - no (explicit) license on docs, only the wiki pages have the "verbatim copying" note. Not hosted on Savannah.
LibreJS - no (explicit) license on docs, hosted on Savannah. GNUMP3d - no license on docs, hosted on Savannah, basically deadGNURadio - uses CC-BY-SA on its wiki and user manual, FDL on its API and developer's manual, not hosted on Savannah (hosted on github ;-;) GNUsound - uses GPLv2+ for everything, hosted on Savannah, basically dead GNU Pascal - no (explicit) license on docs, not hosted on Savannah, basically dead gcl (common lisp) - no (explicit) license on docs, assumed GPL? hosted on Savannah
GnuPG - uses GPLv3+ on docs, not hosted on Savannah ... More info is welcome.Nongnu packages: speaking of approved packages on Savannah, using the filter function on savannah administration group's tasks, there are a little more than 2000 tasks that are marked "done" (approved packages etc.) in the past 10 years, but after 2017, only less than 200 tasks are marked "done", and a few of them are not group submission tasks. Upon checking about 20 of them (which was very emotionally draining for me to see the task comments), nearly all of them don't have documentation at all, which makes sense because a package in its infancy doesn't usually come with docs.
If we don't change the current hosting requirements which mandates docs to be compatible with FDL, we may have to remove a non-trivial amount of packages from Savannah.
> We recommend the FDL because that works better for distributing > printed manuals. But with many instances already of packages > that use the code license for the documentation too, maybe > we should decide that that is ok. You mentioned "FDL..better for distributing printed manual": how about docs that are only distributed digitally, not printed? After all, most programs are not important enough to have the docs to be published inpaperback, and a lot of docs are in the form of html, texinfo, manpage,rst, yaml, etc., and they are a lot like code rather than printed manuals. Not just nongnu packages on Savannah, it might even worth reconsidering the policy of requiring docs to be under FDL for GNU.In the 90s people would want to buy a paperback of GCC reference manual,but I’m not sure it is still true today, and the copies that FSF shop sells are for GCC 3.x (or 4.x ?), very out of date. Maybe people buy/distribute it as a souvenir or a gift or something. We also have a list of "other free books" that are libre but not all compatible with FDL: https://www.gnu.org/doc/other-free-books.html Also, I just thought of another thing: if we say GPL is not compatible with FDL, does it mean that we cannot distribute the source code (GPL) and the manuals (FDL) together? If this is the case then I wonder if there are any GNU packages distributing them together.Hello,The licensing team is happy to help. From what I understand this is mostly a policy decision - we can help explaining what are the consequences of both licenses. And I agree that the challenge is that there are already many files licensed differently, which would have to be relicensed if you insist on a particular license.Please let me know if I'm missing something. I would definitely want to know more why you need compatibility between license for documentation and license for code. I think (but maybe I'm mistaken) that this would matter if code and documentation were intended to be combined into a single work. For joint distribution of code alongside documentation license compatibility is not necessary. I'm open for counter-arguments, though.
A notable example of "code and documentation were intended to be combined into a single work" is manpages. E.g. debian policy requires that every executable must come with a manpage (hence trisquel does too), otherwise such package will be rejected by debian.
But it seems that many people just don't care about the small technicality as long as they are libre. Oh well.
-- Jing Luo About me: https://jing.rocks/about/ GPG Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC
signature.asc
Description: OpenPGP digital signature
