[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Towards a new LPPL draft


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,

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)


  foo.c + foo (original built)


  foo.c + foo.dif + info how to patch (no binary)


  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

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
as well as to some extent binary, simply because there is no translation

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
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,


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
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

 overcite.sty + overcite.dif

leaving it to the receiver to patch the source (but then disallowing that
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).


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
>  this list, and the Debian users that mailed me privately, still believe
>  the requirement for renaming files LaTeX source files when doing
>  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

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

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: