Re: Results for Debian's Position on the GFDL
On 3/13/06, MJ Ray <mjr@phonecoop.coop> wrote:
> I don't see why this is such a bad view of it. I've never thought the
> DFSG-busting anti-DRM was clear-cut: it's mostly suspicion because RMS
> refused to explain it. Justifiable suspicion, but suspicion even so.
I agree.
If someone threatens legal action based on some other
interpretation, we'd probably drop that package simply
because we don't want to be bothered with working with
a hostile copyright holder.
The "technical measures" phrase was clearly intended as a
reference to the law which provides penalties against people
who avoid technical measures intended to enforce copyright.
It could be better, and we can encourage the use of better
licenses, but in and of itself this shouldn't be that big of an
issue.
> The PS says
> nothing about other licences or interpretation of the DFSG. I think it's
> more giving FSF the "benefit of the doubt" on the non-invariant problems
> in FDL. I don't think that's prudent, but maybe I'm in a minority.
Again, I agree.
> 4. The Project's position is what the PS says: that invariant-less-FDL'd
> works meet the requirements of the DFSG and so could go in main (until
> or unless further data is available), but "is still not free of trouble,
> even for works with no invariant sections". So, it remains for ftpmasters
> and RMs to decide how they handle FDL'd works - especially given the
> practical problem of N-year Transparent Copy storage, which is not
> mentioned in the PS at all.
I don't think this is a significant issue.
The GFDL says:
A copy that is not "Transparent" is called "Opaque".
And it gives some examples of what might be "Opaque" copies.
But as long as we the copy includes all required transparent
material, it's not opaque, and we don't need to take any special
steps to retain other copies.
This means that any .deb packages with GFDL'd content
must include full sources -- which creates bulk. But the
ftp site management decision need be no more complicated
than deciding whether or not to include the package at all
(perhaps cutting off bulky low priority packages if resources
are constrained).
> We've stated our views, but the Project as a whole disagrees with some
> of them. So be it. The Project did not ask for Further Discussion of
> this issue at this time. I think they should have, rather than leave a
> 3:2 split on opposing views, but they did not.
For what it's worth: Further Discussion was my first choice on this
issue.
--
Raul
Reply to: