savannah-hackers-public
[Top][All Lists]
Advanced

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

Re: [Savannah-hackers-public] Savannah hosting requirements on documenta


From: Corwin Brust
Subject: Re: [Savannah-hackers-public] Savannah hosting requirements on documentation license (was: Re: [task #16589] Submission of P2P Social Network Pandora)
Date: Mon, 11 Nov 2024 11:19:49 -0600

On Mon, Oct 14, 2024 at 11:44 AM Ineiev <ineiev@gnu.org> wrote:
>
> On Fri, Oct 11, 2024 at 11:16:48PM -0400, 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;
>
> That doesn't mean they release their documentation
> in FDL-incompatible ways; permissive licenses may be both
> GPL- and FDL-compatible.
>
> >     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 think it is more to the point that program authors submitting to
Savannah are not choosing the GFDL - we are pressuring them to do so.
Is this sufficiently important to justify applying such pressure?
Especially considering the many requirements hosting with Savannah
imposes on people, I do not believe it is.  I believe our efforts are
better spent, for example, educating people about the importance of
our forward compatibility ("or any later version") requirement where
that applies.

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

That is my opinion.  Focusing our efforts on what is most valuable
should be our goal especially regarding changes we make to our hosting
requirements (and the processes we follow, for example reviewing
submissions).  In my view these priorities should be, first the
freedom of users of the non-GNU programs we host, secondly making good
use of volunteers' time, and finally to make sure our requirements and
processes are minimal, to the greatest extent possible given the prior
two points. Emphasizing this last: minimizing our requirements to
those absolutely necessary facilitates access and focuses our work -as
volunteers- where that work involves explaining our policies and
helping others understand them and why we have them.

> I think one point to consider is coherency with GNU: non-GNU
> Savannah was provided for hosting to serve as a place where
> GNU packages could take code and documentation from; currently,
> GNU policies include using FDL for manuals, so for that idea
> to work, the documentation of packages hosted on non-GNU Savannah
> should also be FDL-compatible... or the GNU Project could
> reconsider its policies about the documentation.

IIUC, the argument stated is that Non-GNU Savannah packages might
some-day become GNU packages.  Considering this in context of Richards
point (these might someday have a printed manuals and GFDL makes that
simpler by allowing -e.g.- cover art to be listed as invariant), I
find this weak tea:  On the one hand, I do not find documentation in
our hosting guidelines backing up the assertion here given that
hosting on non-GNU Savannah implies any intention to offer the program
to become part of GNU, assign copyright of the the program in question
to FSF, etc.. Moreover, even such intention were accepted as fact
-even stated directly in our hosting guidelines- it feels like a waste
of effort to discuss this with each person who submits a project to
non-GNU savannah: the review associated with submission of the program
for inclusion to GNU would seem a more auspicious moment (and, even
then, I would incline that suggesting the author switch licensing of
documentation to GFDL because we might want to print manuals for the
package should be done on a case-by-case basis when there seems a
reasonable likelihood GNU would like to print and sell such manuals).

Overall: I urge pragmatism on this issue.  We should avoid situations
where we might appear pedantic, especially as submitting a program to
non-GNU savannah may be a first point of contact with GNU proponents.

Let us drop any requirement specifying a license for document (but
especially forcing GFDL) as a requirement for hosting on non-GNU
Savannah, replacing it with a simple suggestion, such as:

Documentation for your program must be provided under GFLD, or a GPL
compatible software license, or any other copy-left license of your
choosing. We recommend GFDL, which is the preferred software license
of the GNU project.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]