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

Re: Non-free RFCs in stretch



Iustin Pop wrote:
> On 2017-03-05 12:41:18, Ben Finney wrote:
> > Sebastiaan Couwenberg <sebastic@xs4all.nl> writes:
> > > I'd like to see a compromise in the DFSG like #4 for standards to
> > > allow their inclusion in Debian when their license at least allows
> > > modification when changing the name or namespace for schemas and the
> > > like.
> >
> > Since that does not describe the license granted in these documents, I
> > don't see why you raise it.
> >
> > On the contrary, I would like to see the license granted in these
> > documents changed to conform to the DFSG, and then they can be
> > included without violating or changing our social contract.
>
> I have to say I lean more on practicality side here, and I don't really
> see a need or reason to have standards documents under the "free to
> modify" clause.

Then they can stay in non-free along with all the other things under a
non-free license.  We had a project-wide decision more than a decade ago
that the DFSG applies to *everything* in main, not just source code.

> Could you try to explain to me why one would need the same liberties for
> source code and standard documents?

Among many other reasons:

- Copying bits of the standard into your code, your comments, or your
  documentation.
- Using a grammar out of the standard to write a parser and/or lexer.
- Parsing interesting bits of the standard to do automatic code
  generation.
- Rendering the standard in a better format.
- Using the standard as the basis for a presentation explaining how it
  works.
- Using the standard as the basis to write another, better standard.
- Using the standard to write a completely different standard that
  incorporates it, in whole or in part.

To pre-answer one of the most common objections to the ability to
modify:

The ability to create a modified version of, say, the deflate RFC does
not in any way change the actual standard for deflate, any more than the
ability to modify zlib creates a new "official" zlib.  You can create
your own version, and label it appropriately; the official version
remains the official version.  Changing a standards document doesn't
change the standard.

This really comes down to a question of endorsement: we determine
whether a standards document represents the "official" version by
looking at whether it has the endorsement of a particular standards
body.

- Josh Triplett


Reply to: