Re: Towards a new LPPL draft
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.
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
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)
and prevent distribution of
foo.c + foo.dif + foo (patched built)
and prevent distribution of
foo (patched built only)
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.
Question 2:
I don't know if you use LaTeX or TeX but assuming you do to some extent,
what exactly do you consider "source" and what "built" in case of a LaTeX
work 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 like putting foo.c through a preprocessor that removes some commments
and writes
foo2.c as the result (the c-code in foo.2.c might be less easy to understand
if not all comments are around, but foo.c may not have had any comments in
the
first place in which case foo.c and foo2.c would be identical).
In fact a lot of people do not bother with .dtx files and keep all comments
in the
.sty file, eg make their work consist of a single file, say,
overcite.sty
In other words, there is (normally) no "binary" in the TeX/LaTeX world but
only "source". The only
binary is TeX the program (which has a different license and is of no
concern
to works under LPPL) and if you like the binary image of the LaTeX kernel
(i.e. latex.fmt) but one could essentially run all documents from the source
files only (building the format on the fly from them)
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).
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).
regards
frank
ps (sorry for the mail format (MS exchange ...))
-----Ursprungliche Nachricht-----
Von: Branden Robinson [mailto:branden@debian.org]
Gesendet: Montag, 22. Juli 2002 23:27
An: debian-legal@lists.debian.org
Betreff: Re: Towards a new LPPL draft
On Mon, Jul 22, 2002 at 09:31:54PM +0200, Frank Mittelbach wrote:
> So to come back to (1):
>
> Axiom: after all discussions the LaTeX Mafia, the LaTeX users that spoke
on
> this list, and the Debian users that mailed me privately, still believe
that
> the requirement for renaming files LaTeX source files when doing
modification
> for distribution is essential and helpful.
>
> What i learned from the discussion is that the license should restrict
this to
> what we actually need (eg not makefiles, tar balls, etc).
[...]
> A) I would like you to come to a conclusion on (1) assuming the above
Axiom
In my opinion, this is a restriction on modification that violates DFSG
3. DFSG 4 offers no safe harbor for this particular requirement.
To review:
3. Derived Works
The license must allow modifications and derived works, and must
allow them to be distributed under the same terms as the license
of the original software.
4. Integrity of The Author's Source Code
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.
It is apparently the desire of the LaTeX project that the LPPL "restrict
source-code from being distributed in modified form" under a
circumstance *other* than "the distribution of "patch files" with the
source code for the purpose of modifying the program at build time."
Any license with that property fails the DFSG.
The license must explicitly permit distribution of software
built from modified source code. The license may require derived
works to carry a different name or version number from the
original software.
Note that it is the *work* for which a mandate to rename is permitted.
The "name" of a "work" is a legal construct which may or may not have
any bearing on filenames, file systems, file handles, or other details
of technical implementation.
(This is a compromise. The Debian group encourages all authors
not to restrict any files, source or binary, from being
modified.)
--
G. Branden Robinson | There is no housing shortage in
Debian GNU/Linux | Lincoln today -- just a rumor that
branden@debian.org | is put about by people who have
http://people.debian.org/~branden/ | nowhere to live. -- G. L. Murfin
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: