On Tue, Jul 23, 2002 at 02:19:15PM +0100, Mittelbach, Frank wrote:
> Branden,
>
> can you do me the favor and try to clearify for me when in your
> opinion the DSFG 4 clause is applicable for a license.
Sure. Before getting to your hypotheticals, I'll try and give you a
direct, if generalized, answer.
A license must be tested against DFSG 4 when either of the following are
true:
A) the license places restrictions on the form in which modifications to
the Work are distributed;
B) the license places restrictions on the manner in which the Work is
named or versioned.
Without DFSG 4, *any* license term did either of the above would violate
violate DFSG 3.
In practice, DFSG 3 is not held to apply to copyright notices or license
terms that are applicable-in-fact to the Work. (I.e., it must be
permitted to remove copyright notices and license terms when you are
also removing all of the code that is covered by that copyright notice
and license.) Admittedly, this nuance is not stated directly in the
DFSG, but if one thinks carefully about copyright law, it may be argued
that it follows from DFSG 9. (In other words, the license on your Work
is not permitted to tamper with a person's rights with respect to
another Work that has no relationship -- or no longer has a relationship
-- to your Work. Some people have, in the past, erroneously claimed
that the GNU GPL violates DFSG 9, but this is not true -- the GNU GPL
applies only to works distributed under its terms.)
> Question 1:
>
> Suppose you have a program source foo.c with some license. Suppose
> this license "restricts" foo.c from being modified but allows
> distribution of foo.c plus a patch file, e.g. foo.dif and allows to
> patch foo.c at built time, i.e.
>
> patch < foo.dif
> gcc foo
>
> NOW: would it be acceptable for the license to disallow distribution
> of the modified built
No. Quoting DFSG 4:
"The license must explicitly permit distribution of software built from
modified source code."
A license cannot disallow distribution of the "binary" built from
modified sources and be DFSG-free unless the license is terminated for
non-compliance. (In other words, you don't have to permit people to
distribute binaries built from modified sources after they violate your
license, just as you don't have to permit the exercise of any other
right reserved to you under copyright law under such circumstances.
However, in and of itself, the distribution of "binaries" built from
modified sources must be permitted by the license for the license to be
DFSG-free.)
> and to only allow distribution of either
>
> foo.c (alone)
> or
>
> foo.c + foo (original built)
> or
>
> foo.c + foo.dif + info how to patch (no binary)
> or
>
> foo.c + foo (original built) + foo.dif + infor how to patch and renerate a
> modified binary
>
> but prevent the distribution of
>
> foo.c + foo (patched built)
This would fail DFSG 4: "The license must explicitly permit distribution
of software built from modified source code."
> and prevent distribution of
>
> foo.c + foo.dif + foo (patched built)
This would fail DFSG 4: "The license must explicitly permit distribution
of software built from modified source code."
> and prevent distribution of
>
> foo (patched built only)
This would fail DFSG 4: "The license must explicitly permit distribution
of software built from modified source code."
> is that what you think
>
> The license may restrict source-code from being distributed in
> modified form _only_ if the license allows the distribution of
> "patch files" with the source code for the purpose of modifying
> the program at build time.
>
> means? I guess the answer might be no, but i would like to get a clear
> picture.
You are correct. I do not think that DFSG 4 can plausibly be read to
permit the the restrictions you posit in your hypothetical.
> Question 2:
>
> I don't know if you use LaTeX or TeX but assuming you do to some extent,
I have used LaTeX in the past but only at a highly rudimentary level; I
understand almost nothing of its internals.
> what exactly do you consider "source" and what "built" in case of a LaTeX
> work
That's an excellent question and it illustrates a vagueness in the
wording of the DFSG. The DFSG misleadingly speaks in terms of "source"
and "binary" when in many situations, as folks have noted on this list,
the distinctions are not applicable, at least not in the same way that
they are to compiled C programs.
It is my opinion that when the DFSG speaks of "source", it is referring
to that which is in a Debian "source package". In the case of
freely-licensed software, this is an archive of files/code/data that is
the "preferred form for making modifications to the Work" (in the
language of the GNU GPL). Some non-free Debian source packages, such as
Netscape Navigator, (used to) contain actual binaries because source
code is not available, but these are anomalies.
Likewise, it is my opinion that when the DFSG speaks of "binaries", it
is referring to that which is distributed in a Debian binary package, or
".deb", and is the form of the software or other work which is of
immediate utility to the user when the package is installed to the
system. Debian binary packages strive to be immediately usable without
manual configuration by the user, however sometimes this is not
possible. There is, of course, only a fuzzy line between the
configuration process of some software and the compilation process of
other software. I.e., how different is the generation of sendmail.cf
from sendmail.mc from ordinary compilation? The DFSG doesn't really
address this issue.
At any rate, in my opinion, the definitions that Debian uses for
"source" and "binary" in the DFSG are operative ones based on the user
experience. (Note that the DFSG is an adjunct document to the Debian
Social Contract, which emphasizes Debian's commitment to its users.)
Debian attempts to have our binary packages install to the user's system
with as little post-installation processing as possible, mitigated by at
least a couple of factors:
1) differing configuration needs on the users' part
2) the size of the binary package
1) is why we don't ship mail transfer agents pre-configured, and 2) is
one reason Emacs Lisp files are compiled into bytecode after
installation as opposed to shipping pre-compiled bytecode inside the
package.
> like varioref consisting of the files
>
> varioref.dtx varioref.sty (and varioref.ins to easily convert the first in
> the second)
> There varioref.sty is a version of varioref.dtx with some comments
> removed, but as far as TEX/LaTeX is concerned both files could be
> considered both source as well as to some extent binary, simply
> because there is no translation step.
It is not the perspective of the work itself that is primary when
applying the DFSG, but the needs of the users.
I would argue that the following sentence of DFSG 4:
The license may restrict source-code from being distributed in
modified form _only_ if the license allows the distribution of
"patch files" with the source code for the purpose of modifying
the program at build time.
is inapplicable when a Work consists entirely of code that is translated
into machine language at run-time, as is the case with interpreted
languages. For the intents and purposes of the DFSG, the binary and
source forms are the same; there is no "build time" to which the above
exception can attach.
As I said earlier, the entire reason this sentence exists, as I
understand it, was as the result of an unsuccessful effort to persuade
Daniel J. Bernstein and/or the University of Washington to license some
software under DFSG-free terms. In both of those cases (qmail, pine,
etc.), those efforts failed. I don't know of any currently DFSG-free
Debian packages that would be rendered DFSG-non-free if this sentence
were deleted from the DFSG. (I invite the folks on debian-legal to
correct my ignorance if I am mistaken.)
> In other words, there is (normally) no "binary" in the TeX/LaTeX world
> but only "source".
In that case the patch-files exception in DFSG 4 is not available to
you, in my assessment.
> So when applying DSFG#4's patch condition: would it be okay to have a
> license that forbits to change overcite.sty and only allows
> distributing derived works by distributing
>
> overcite.sty + overcite.dif
>
> leaving it to the receiver to patch the source (but then disallowing
> that this patched sources is further distributed).
In my opinion, no, a license could not do this and satisfy DFSG 4.
The license must explicitly permit distribution of software
built from modified source code.
If there is no "binary" in the TeX/LaTeX world, but only "source", then
the only way to satisfy DFSG 4 is to explicitly permit distribution of
modified software.
I guess it is possible that you are thinking about the source/binary
dichotomy in one way, which leads you to regard the second sentence of
DFSG 4 as inapplicable to TeX/LaTeX, and I am thinking about the
source/binary dichotomy in another way, which is leading me to regard
the first sentence of DFSG 4 as inapplicable to TeX/LaTeX.
In my opinion, my interpretation of the source/binary binary dichotomy
is more consistent with Debian's tradition, in that we are not looking
for loopholes through which we will tolerate the suppression of users'
rights to modify the software they get from Debian, and redistribute
their modifications to their neighbors.
> If you could answer me the above questions that would be very helpful
> indeed as it might mean we could compromise on allowing patches as an
> alternative to file renames (could I said).
I concur with Jeff Licquia's suggestion. If one can avoid the filename
renaming requirement by simply renaming the entire Work and not
representing it as "LaTeX" but rather as "SniffenTeX" or whatever, then
that would be the avenue that Debian could use in the event we ever
needed to change LaTeX. From our perspective, LaTeX would be
"dual-licensed". That both licenses would be embodied in the same
document isn't really important.
--
G. Branden Robinson | Communism is just one step on the
Debian GNU/Linux | long road from capitalism to
branden@debian.org | capitalism.
http://people.debian.org/~branden/ | -- Russian saying
Attachment:
pgpYKcsPmwi8m.pgp
Description: PGP signature