Re: Non-free RFCs in stretch
- Date: Sun, 5 Mar 2017 17:33:44 -0800
- From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
- Subject: Re: Non-free RFCs in stretch
Iustin Pop wrote:
> On 2017-03-05 12:41:18, Ben Finney wrote:
> > Sebastiaan Couwenberg <sebastic@xxxxxxxxx> 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
- Using a grammar out of the standard to write a parser and/or lexer.
- Parsing interesting bits of the standard to do automatic code
- Rendering the standard in a better format.
- Using the standard as the basis for a presentation explaining how it
- 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
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
- Josh Triplett