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

Re: GFDL GR: Amendment: no significant invariant sections in main



Le Dim 12 Février 2006 02:22, Osamu Aoki a écrit :
> Hi,
>
> I second Adeodato Simó's proposal but at the same time I consider it
> still leaves some spaces for the absolutism interpretation which
> tends to plague Debian.  I consider we should have reasonable space
> for "judgment" for many things in life.
>
> Let's consider a documentation written in the SGML and released under
> GFDL in which invariant section is claimed but its invariant section
> is in commented-out section which contain nothing but list of author
> name and their contact e-mail address.  This is a really possible
> case since people consider putting their e-mail addresses in
> printable contents tends to cause headache with spams.
>
>  GFDL blah, blah,...
>  Invariant section being following comment section in SGML
>  <!--
>    chapter 1: author1_name name1@isp.dom
>    chapter 2: author2_name name2@isp.dom
>  -->
>
> Under literal rule of Adeodato Simó's proposal, above GFDL
> documentation can not be in "main" since author forgot to place
> removal rule for the content. I consider GFDL documentation with such
> non-significant contents should receive the same treatment as the
> invariant-less GFDL documentation.  Other possible GFDL invariant
> section which, I consider, should be permitted is an advertisement
> clause by the author or publisher.  I see no difference from 4 clause
> BSD license.
>
> Thus, let me propose an amendment to Adeodato Simó's proposal:
>
>  s/include no invariant sections/don't include any significant
> contents to prevent our Freedom in invariant sections/ and matching
> changes to the text.
>
> So here is my proposal in full text:
> -----------------------------------8<--------------------------------
>---
>
> Debian and the GNU Free Documentation License
> =============================================
>
> This is the position of the Debian Project about the GNU Free
> Documentation License as published by the Free Software Foundation:
>
>   1. We consider that the GNU Free Documentation License version 1.2
>      conflicts with traditional requirements for free software, since
> it allows for non-removable, non-modifiable parts to be present in
> documents licensed under it. Such parts are commonly referred to as
> "invariant sections", and are described in Section 4 of the GFDL.
>
>      As modifiability is a fundamental requirement of the Debian Free
>      Software Guidelines, this restriction is not acceptable for us,
> and we cannot accept in our distribution works that include such
> unmodifiable content.
>
>   2. At the same time, we also consider that works licensed under the
>      GNU Free Documentation License that don't include any
> significant contents to prevent our Freedom in invariant sections do
> fully meet the requirements of the Debian Free Software Guidelines.
>
>      This means that works that don't include any significant
> contents to prevent our Freedom in Invariant Sections, Cover Texts,
> Acknowledgements, and Dedications (or that do, but permission to
> remove them is explicitly granted), are suitable for the main
> component of our distribution.
>
>   3. Despite the above, GFDL'd documentation is still not free of
>      trouble, even for works with no invariant sections: as an
> example, it is incompatible with the major free software licenses,
> which means that GFDL'd text can't be incorporated into free
> programs.
>
>      For this reason, we encourage documentation authors to license
>      their works (or dual-license, together with the GFDL) under the
>      same terms as the software they refer to, or any of the
> traditional free software licenses like the the GPL or the BSD
> license.

my understanding of this is that it's a minor problem, that upstreams 
are likely to solve easily. I hope dato  won't accept that as a 
amendment of his proposal, because I think it changes it spirit a lot, 
and I won't second it.

There is no need to draw a blurry line, for problems that a maintainer 
and upstream are really likely to solve in peace.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpPfVS8vkMFO.pgp
Description: PGP signature


Reply to: