Re: Bug#374569: groff-base: groff-base includes non-free material
On Thu, Aug 10, 2006 at 04:45:35PM +0100, Colin Watson wrote:
> I'm on holiday away from computers all next week, so I can't
> realistically do anything before the base freeze. I therefore have two
> proposals, either of which really ought to be signed off by the release
> One is to do nothing for now, and make an exception for the groff
> licensing bug on the bases that (a) groff is nearly unusable for
> authoring without its documentation and (b) upstream considers the
> current versions of those files to be GPL-licensed. I wouldn't make that
> request based on (a) alone - we've had the "but it's too useful to be
> non-free!" whine many times before, and I don't think it's valid - but
> given (b) it seems to be worth considering. I don't think that splitting
> off groff's documentation is a good idea, because aside from the small
> man-page-formatting-only part of groff that's in groff-base, the rest of
> the groff package is really too painful to use without its
> documentation: much harder than e.g. make without make-doc. I'm willing
> to go to almost any lengths to avoid that option.
> The other option is to try to accelerate the implementation of glyph
> classes, width handling, and kinsoku shori handling in groff as much as
> possible, so that we can update to CVS groff (perhaps with some
> additional patches) and not regress CJK support too badly. This would
> also require changes in man-db. Obviously, this would require getting
> testing from several CJK users to confirm that the output is still
> reasonably readable, and it involves an exception to the base freeze.
> How does the release team feel about all of this? I'm sorry to have left
> it so late.
Is there any chance that the documentation from the latest version of groff
is suitably applicable to the version we're currently shipping as to allow
dropping in the GPLed version of the documentation?
Also, are width handling and kinsoku shori handling features present in the
current groff patch set, such that their loss would be regressions when
moving to the new upstream version?
Of the two options you've offered, I would favor the first one, to grant an
exception on the grounds that it's upstream's intent to make the
documentation available under the GPL. The latter option doesn't really
sound to me like a recipe for success, at least from the POV of the CJK
community. OTOH, if an ok on the first option happened to free you up to
work on the code for option #2 rather than chasing licenses, I'd be happy to
reconsider that option once the solution is farther along.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.