On Tue, Oct 29, 2002 at 09:03:31PM +0100, Javier Fernández-Sanguino Peña wrote:
> On Tue, Oct 29, 2002 at 01:02:20PM -0500, Branden Robinson wrote:
> > On Tue, Oct 29, 2002 at 12:36:28PM +0100, Javier Fernández-Sanguino Peña wrote:
> > > May I remark the phrase "The copyright in such work is
> > > independent of (...) any copyright protection in the preexisting
> > > material."
> >
> > "Independent of" doesn't mean "supersedes". It means "coexists with".
>
> "Coexist" doesn't mean that the original "supersedes" the
> translation, they can be different.
Correct. So you are only permitted to do what the intersection of both
licenses's grants of permission indicate.
> > Exactly. The original copyright still applies.
> >
> No it doesn't.
> The original copyright applies to the original work.
> The translation's copyright applies to the translation.
Under U.S. law, which is the only law I'm interested in arguing about at
the moment:
A ''derivative work'' is a work based upon one or more
preexisting works, such as a translation, musical arrangement,
^^^^^^^^^^^
dramatization, fictionalization, motion picture version, sound
recording, art reproduction, abridgment, condensation, or any
other form in which a work may be recast, transformed, or
adapted. A work consisting of editorial revisions, annotations,
elaborations, or other modifications which, as a whole, represent
an original work of authorship, is a ''derivative work''.
(U.S. Code Title 17, Chapter 1, Section 101.[1])
Exclusive rights in copyrighted works
Subject to sections 107 through 121, the owner of copyright under
this title has the exclusive rights to do and to authorize any of
the following:
(1) to reproduce the copyrighted work in copies or
phonorecords;
(2) to prepare derivative works based upon the copyrighted
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
work;
^^^^
(U.S. Code Title 17, Chapter 1, Section 106.[2])
A grant of permission to prepare a translation does not imply an
assignment of copyright. A derivative work such as a translation MAY
constitute an original work on its own, but this does NOT supersede or
in any way eliminate any of the exclusive rights possessed by the
owner of the work being derived.
For example, I may make a derivative work of GNU Emacs and XFree86,
incorporating some code from each work in addition to some original
work of my own.
The fact that I can place a notice:
Copyright 2002 Branden Robinson
on my work does NOT mean that the copyrights in GNU Emacs and XFree86
go away. I and everyone else are still bound by the license terms on
those works, which include the requirement that I preserve existing
copyright notices:
Copyright 1990 Free Software Foundation
Copyright 1994 The XFree86 Project, Inc.
All three copyright notices should appear in the work because all
three copyrights exist in the work.
> > So the two copyrights exist together on the translated work.
> >
> NO!!!!!
There is no need to scream, and, by the way, you're wrong.
> I'm starting to think I do have a communication problem here.
>
> > Any DFSG-free license will grant license to produce translations, since
> > translation is a form of modification.
>
> I'm not sure that's valid under copyright law.
Well, there goes most of Debian's localization work, then.
Fortunately, I speak English.
Your argument is complete nonsense, at least under U.S. law. The
right in any DFSG-free license to modify implies permission to create
"derived works".
If I grant you the right to "modify" my copyrighted work, do you have
the right to:
* arrange it as a piece of music;
* dramatize it;
* fictionalize it;
* create a motion picture version;
* create a sound recording of some performance of it;
* reproduce it as a work of art, as a painting or photograph, for
instance;
* abridge it;
* condense it;
* do anything to it such that it may be "recast", "transformed", or
"adapted";
* editorially revise it;
* annotate it;
* elaborate on it;
* modify it in some other way not listed above
?
If not, then DSFG 3 is meaningless, for permission to "modify" under a
copyright license would therefore mean very little at all. Code could
neither be added to ("elaborated") nor removed ("abridged" or
"condensed") from it. People wouldn't even have permission to add
comments to it ("annotation").
If, on the other hand, "modification" means any of the above, then,
under U.S. law, "translation" is included as well. U.S. Code Title
17, Chapter 1, Section 106.
> I read this a long time ago.
>
> I question the ftp-maintainer because he did *not* file a bug,
Why are the archive admins required to file a bug? I grant you that
it would be nice if they were to do so, but it is not my understanding
that the archive administrators' responsibility is to perform audits,
either one-time or recurring, of packages *already in* the Debian
archive that don't call attention to themselves.
It *is* one of their responsibilities to make an effort to vet the
licensing on new, or substantially new[3] packages that come to their
attention.
There are many ways a package maintainer could sneak DFSG-non-free
code into a package in such a way that the archive admins would miss
it. That's why the primary responsibility is on the package
maintainer to vet the licenses on his or her packages.
That does not mean, however, that each package maintainer has the
final say on whether or not his or her package satisfies the DFSG and
should be accepted into the main archive. Those are collective
decisions that are made by interested parties in the Project.
Determinations of DSFG-freeness are made primarily by the debian-legal
mailing list. Determinations as to whether a package will be accepted
into the main archive are made primarily by the archive
administrators. These are not the same decision. It is perfectly
possible to have a source package that is uncontroversially DFSG-free
but unacceptable for inclusion in the archive. It may, for instance,
be 10GB in size.
> he REJECTED the package based on this when the package in
> woody/sarge whatever has not been bugged.
An archive administrator perceived a potential license problem with a
package and rejected it for that reason. That is all that he is
required to do.
If debian-legal or the developers in general, by way of a General
Resolution or some other procedure, decided to overrule the archive
administrators, I would expect them to honor the decision so made.
However, that does not look likely in this situation.
> I'm not going to do it BTW. Feel free to do so.
The ldp-es package should be removed from Debian because of its
licensing problems. I may file a bug to that effect, but let's see if
this thread winds down soon. Perhaps we can all reach a better
consensus, and that can be reflected in the bug report.
> > I have not heard anyone proposing that ldp-es receive discriminatory
> > treatment. If other translations of the ldp package, and/or the ldp
> > package itself, have licensing problems, then they require our
> > attention.
>
> A package that is removed from incoming when the bug has not been
> reported *is* discrimination.
I am aware of no procedure that requires bugs to be filed in
conjunction with package rejections by the archive administrators. It
might be nice if there were more of a paper trail for such things,
but I do not see how you can plausibly claim discriminatory behavior.
The archive administrators do not, as far as I am aware, file bugs in
conjunction with their "REJECTED" messages under any circumstances at
all.
> I don't object against doc-rfc being pulled out of Debian (although
> I do lament it) but I don't think ftp-maint has acted properly here.
I am not the most uncritical observer of Debian's archive
administration team, but I disagree with you. I perceive no
irregularity or impropriety here.
> But that's another issue.
Yes. If you want to talk about proper procedure for the archive
administrators, -project is a more appropriate mailing list. -legal
should stick to DFSG-freeness and related issues.
> > Lawsuits, both real and threatened, against Free Software
> > developers from large software companies and speech-suppressing
> > laws like the DMCA are largely responsible for the increased level
> > of scrutiny that licensing issues receive, not just in Debian but
> > in the Free Software community in general.
>
> Agreed. But it seems a little bit excesive to prevent a package from
> fixing a RC bug when there is no such threat.
Debian tries to be non-discriminatory in its application of the DFSG.
That way may not expect a lawsuit from the copyright holders the
documents in the ldp-es package is no reason for us to disregard their
license, especially when there are no apparent illegitmate claims of
copyright or claims to exclusive rights not permitted by copyright
law.
> These documentation, and all translations, are being distributed in
> TLDP (The Linux Documentation Project). Debian would be the last
> place to have issues.
Uh, you're just plain wrong about this.
http://www.tldp.org/ldpwn/ldpwn-2001-12-04.html
http://lists.debian.org/debian-legal/2001/debian-legal-200112/msg00052.html
> In any case I'm trying to normalise the licensing issues with the people
> at LuCAS. However I'm afraid that no one has analised the many issues that
> we can find on our documentation-only packages and translations:
>
> $ apt-cache search doc- |wc -l
> 89
As I understand it, Colin Watson undertook just such an analysis last
year.
> We need a policy regarding which documentation is going to be allowed into
> Debian, and the DFSG IMHO do not apply to documentation properly (but
> let's not get into *that* thread again).
Attempting to resurrect a very long and contentious thread with
ramifications involving an amendment to the Debian Constitution is not a
very constructive response to an archive administrator acting in a way
you don't personally agree with. Especially when you appear to be the
only person who feels that they did so, or that the Berne Convention
means what you think it means. To do so just makes it look like you're
motivated out of personal frustration over your rejected upload rather
than any sort of principled objection.
[1] http://caselaw.lp.findlaw.com/casecode/uscodes/17/chapters/1/sections/section_101.html
[2] http://caselaw.lp.findlaw.com/casecode/uscodes/17/chapters/1/sections/section_106.html
[3] i.e., something that looks "new" to katie, as happens when an
existing package adds a new binary package, such as when
"xserver-xfree86-dbg" recently became a binary package of the
"xfree86" source package
--
G. Branden Robinson |
Debian GNU/Linux | Cogitationis poenam nemo meretur.
branden@debian.org |
http://people.debian.org/~branden/ |
Attachment:
pgpOfI9mgTMhQ.pgp
Description: PGP signature