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

analysis of latest LPPL revision (1/2)



On Wed, Jun 18, 2003 at 01:24:09AM -0500, Jeff Licquia wrote:
> After the last round of discussions, the LaTeX Project has asked me to
> review and present a new revision of the LPPL, which is attached below.
> 
> It is unlikely that I will be able to participate in the discussion this
> time around due to time constraints, but the LaTeX people should be
> around to hear your feedback.
> 
> The parts of the license that have caused the most friction in the past
> are now fully contained within clause 6.  I doubt that any other part of
> the license will be seen as objectionable (except, possibly, in their
> invokation of clause 6).  It is my opinion that clause 6 does not
> violate the Debian Free Software Guidelines.

Okay, well, no one on this list has yet given this license the hairy
eyeball, so I guess the task falls to me.

My remarks will be categorized so that the LPPL team has some help in
triaging these issues.  People unfamiliar with my rhetorical style may
not be able to distinguish my nitpicking from my screeching complaints.
:)

Categories
----------
cosmetic nit: a typographical issue; failure to rectify this should have
  no real consequences at all

semantic nit: a wording issue that I does not, in my opinion, obscure
  the meaning or intent of the license to an intelligent reader who is
  unversed in licensing issues

semantic wart: a wording issue that I think may be misleading or
  confusing even to an intelligent reader fairly conversant with
  licensing issues; an issue that could cause people to misinterpret or
  be confused by the meaning of the license

DFSG problem: a semantic wart that renders the license DFSG-non-free as
  applied to a hypothetialc work using its terms

aside: just chatting

I have defined these categories prospectively while writing this mail;
the existence of a category does not necessarily mean there are any
instances of issues so categorized in this license analysis.  :)

> PREAMBLE
> ========
> 
> The LaTeX Project Public License (LPPL) is the license under which the
> the LaTeX kernel and the base LaTeX packages are distributed.

[semantic nit] It may be the primary license under which such things are
distributed, but is it really the only one, past, present, and future?

I suggest: s/the license/the primary license/

> You may use this license for any work that you have written and wish
> to distribute.

[semantic nit] Copyright does not apply to all works, and is alienable;
therefore the fact that I have written a work does not mean I am
entitled to copyright protection (it may be "unoriginal" under, e.g.,
U.S. copyright law), or I may not own the copyright in the work even
though I wrote it (e.g., I may have assigned the copyright or it may
have been a "work for hire").  Futhermore, I may hold the copyright for
works I did not write --- that does not mean that I cannot apply the
LPPL to such a work.

I suggest: s/that you have written/for which you hold the copyright/

> This license may be particularly suitable if your
> work is TeX-related (such as a LaTeX package), but you may use it
> with small modifications even if your work is unrelated to TeX.
> 
> The section `WHETHER AND HOW TO DISTRIBUTE WORKS UNDER THIS LICENSE',

[cosmetic nit] http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
(People can and do disagree on this issue, so I will simply provide the
citation and move along.)

> below, gives instructions, examples, and recommendations for authors
> who are considering distributing their works under this license.
> 
> This license gives conditions under which The Work may be distributed
> and modified, as well as conditions under which modified versions of
> The Work may be distributed.

[semantic nit] "The Work" is not yet defined, and since the Preamble is
probably not binding -- since it is disjunct from "CONDITIONS ON
DISTRIBUTION AND MODIFICATION" below, I would substitute "the work so
licensed".

> We, the LaTeX3 Project, believe that the conditions below give you
> the freedom to make and distribute modified versions of The Work
> that conform with whatever technical specifications you wish while
> maintaining the availability, integrity, and reliability of
> The Work.  If you do not see how to achieve your goal while
> meeting these conditions, then read the document `cfgguide.tex'
> and `modguide.tex' in the base LaTeX distribution for suggestions.

[semantic nit] as above; "The Work" is not yet defined.

[aside] I applaud the fact that you're keeping a lot of non-license
material outside the license document itself.

> DEFINITIONS
> ===========
> 
> In this license document the following terms are used:
> 
>    `The Work'
>     Any work being distributed under this License.

[cosmetic nit] It is not quite standard English to capitalize an article
in conjunction with a proper noun, though it is often done for humor or
emphasis.  In my opinion it is not necessary for a formal license
document to do this, and not doing it will not obscure the meaning of
the term or the license.  If people can't see one capital letter I doubt
they'll see a second one.

I suggest: s/The Work/Work/ here and s/The Work/the Work/ everywhere
else in the document (except the "PREAMBLE"; see above).

>    `Derived Work'
>     Any work that under any applicable law is derived from The Work.
> 
>    `Modification' 
>     Any procedure that produces a Derived Work under any applicable
>     law -- for example, the production of a file containing an
>     original file associated with The Work or a significant portion of
>     such a file, either verbatim or with modifications and/or
>     translated into another language.
> 
>    `Modify'
>     Apply any procedure that produces a Derived Work under any
>     applicable law.

[cosmetic nit] I would put the verb in the infinitive so that the
sentence cannot conceivably be mistaken for an imperative.

I suggest: s/Apply/To apply/

>    `Distribution'    
>     Making copies of The Work available from one machine to another,
>     in whole or in part.  Distribution includes (but is not limited to)
>     making any files associated with The Work accessible by file
>     transfer protocols such as FTP or HTTP or by sharing file systems
>     such as Sun's Network File System (NFS).

[DFSG problem] This definition of "Distribution" technically excludes
non-electronic means of distribution, such as by printing out copies of
the LaTeX kernel source code on paper and selling the copies.  This does
not violate a specific clause of the DFSG, but the Debian Project
generally understands "freedom to distribute" as including
non-electronic means.  Futhermore, in the eyes of the law it is people
who engage in distribution, not machines.  I am pretty sure you guys
didn't mean to exclude non-electronic distribution, so hopefully it's
not a big deal.  I apologize for not noticing this before.

I suggest: s/machine/person/
           s/making any files/electronic means, such as making any files/

[cosmetic nit] s/sharing/shared/

>    `Compiled Work'
>     A version of The Work that has been processed into a form where it
>     is directly usable on a computer system.  This processing may
>     include using installation facilities provided by The Work,
>     transformations of The Work, copying of files in The Work, or
>     other activities.  Note that modification of any installation
>     facilities provided by The Work constitutes modification of The
>     Work.
> 
>    `Current Maintainer'
>     A person or persons nominated as such within The Work's sources.
>     If there is no such explicit nomination then it is the Copyright
>     Holder.

[semantic wart] "sources" is not defined.  A nefarious person might
attempt to chisel this into a loophole, though I can't think of a way
that would be meaningful within the context off the top of my head.

I suggest: defining "source", if you can come up with a reasonable
definition.  The GNU GPL has a definition of source code, "The source
code for a work means the preferred form of the work for making
modifications to it.", but it proceeds to elaborate on this, and, as
we've seen recently on debian-legal, even this definition is subject to
argument.  I'll understand if you feel you should punt on the issue and
leave the term undefined.

>    `Base Interpreter' 
>     A program or process that is normally needed for running or
>     interpreting a part or the whole of The Work.    
>     A Base Interpreter may depend on external components but these
>     are not considered part of the Base Interpreter provided that
>     external component clearly identifies itself whenever it is used
>     interactively.

[cosmetic nit] In my opinion, this sentence would read better with the
word "each" in it.

I suggest: s/external component/each external component/

>     Unless explicitly specified when applying the
>     license to The Work the only applicable Base Interpreter is a
>     "LaTeX-Format".

[cosmetic nit] That dependent clause is pretty long.

I suggest: s/Work/Work,/

> CONDITIONS ON DISTRIBUTION AND MODIFICATION
> ===========================================
> 
> 1.  Activities other than distribution and/or modification of The Work
> are not covered by this license; they are outside its scope.  In
> particular, the act of running The Work is not restricted and no
> requirements are made concerning any offers of support for The Work.

[aside] Activist types like myself attempt to defend the notion that
copyright law does not restrict the act of modification per se, but only
the act of distribution, which may or may not be of works modified from
their original form.

> 2.  You may distribute a complete, unmodified copy of The Work as you
> received it.  Distribution of only part of The Work is considered
> modification of The Work, and no right to distribute such a Derived
> Work may be assumed under the terms of this clause.

[semantic nit] I think that last sentence might start to scare people.

I suggest: Append the sentence "However, see the remaining conditions of
this license."

On the other hand, maybe that's not necessary.  I'm of two minds on
this, and it's not really a big deal either way, hence "nit".

> 3.  You may distribute a Compiled Work that has been generated from a
> complete, unmodified copy of The Work as distributed under Clause 2
> above, as long as that Compiled Work is distributed in such a way that
> the recipients may install the Compiled Work on their system exactly
> as it would have been installed if they generated a Compiled Work
> directly from The Work.

[aside] It may be difficult for the distributor to know this, so fearful
types might not exercise their rights under this clause.  However, such
folks can always just distribute under clause 2.  Except that doesn't
talk about Compiled Works...hmmm...

[semantic wart] I see no explicit authorization or encouragement to
distribute a Compiled Work that has been generated from a complete,
unmodified copy of The Work in *conjunction* with a complete, unmodified
copy of The Work as recived by the distributor.  Or wait, maybe this
isn't disjunct after all.  No, I guess it isn't.  I leave this point in
place only to illustrate my momentary confusion.  If that inspires you
guys to tweak the wording just a bit, have at it.  Otherwise, just
prepare a FAQ entry for it, unless you think I'm the only one who will
ever sweat this.  :)

> 4.  If you are the Current Maintainer of The Work, you may modify The
> Work, creating a Derived Work, without restriction.

[cosmetic nit] I see a way to be even more emphatic about what is meant.

I suggest: /creating/thus creating/

[aside] Ah, I see you guys used that construction below.  Good, good ---
might want to add it here.  :)

[aside] Again, activists like myself would prefer that free licenses
explicitly disclaimed the authority to tell people they cannot make
moficiations to copyrighted works.

> You may also distribute the Derived Work without restriction,
> including Compiled Works generated from the Derived Work.  Derived
> Works distributed in this manner by the Current Maintainer are
> considered to be updated versions of The Work.
> 
> 5.  If you are not the Current Maintainer of The Work, you may modify
> your copy of The Work, thus creating a Derived Work based on The Work,
> and compile this Derived Work, thus creating a Compiled Work based on
> the Derived Work.

[aside] Again, activists like myself would prefer that free licenses
explicitly disclaimed the authority to tell people they cannot make
moficiations to copyrighted works, or cannot compile them.

If that were made explicit in clause 1, then this clause could be
stricken entirely, since this clause doesn't even mention distribution.

> 6.  If you are not the Current Maintainer of The Work, you may
> distribute a Derived Work provided the following conditions are met
> for every component of the Work unless that component is clearly
> stated to be exempt from that condition.

[semantic wart] Stated where, when, and/or by whom?

I suggest: s/is clearly stated to be exempt from that condition/clearly
states its exemption from that condition in the copyright notice of its
source.  Only the Current Maintainer is authorized under this license to
add such exemption statements to components of the work/

[aside] That's the loophole to which I was referring my previous mail.

>   a. If a component of this Derived Work can be a direct replacement
>      for a component of The Work when that component is used with the
>      Base Interpreter, then, wherever this component of The Work
>      identifies itself to the user when used interactively with that
>      Base Interpreter, the replacement component of this Derived Work
>      clearly and unambiguously identifies itself as a modified version
>      of this component to the user when used interactively with that
>      Base Interpreter.
>      
>   b. Every file of the Derived Work contains prominent notices

[semantic nit] "File" is not defined --- it is a technological concept
more than a legal one.  I know the LaTeX and Debian Projects have gone
round and round about files and filenames, so I apologize for bringing
it up again.  I think it would be better to speak at the logical level
of "component", as done elsewhere, instead of at the technological level
of "file".  I do remind the reader that this is just a nit.  :)

I suggest: s/file/component/

>      detailing the nature of the changes, or a prominent reference
>      to another file that is distributed as part of the Derived Work
>      and that contains a complete and accurate log of the changes.

[semantic wart] Of the changes to what?

I suggest: s/changes/changes to the component/ (or furthermore
s/component/file/, if you disagree with my reasoning in the previous
item)

>   c. No information in the Derived Work implies that the authors of
>      the original version of The Work provide any support, including
>      (but not limited to) the reporting and handling of errors, to
>      recipients of the Derived Work unless those authors have stated
>      explicitly that they do provide such support for the Derived Work.

[aside] It is interesting, and possibly correct and preferable, that
this clause speaks of the "authors" of the work rather than the
copyright holder or Current Maintainer.

[semantic nit] You may, however, wish to expand this clause to get them
under the umbrella of protection from implied support as well.

I suggest: s/authors/authors, copyright holders, or past or present
Current Maintainers/

[semantic nit] "past Current Maintainers" sounds kind of funny --- maybe
s/Current Maintainer/Maintainer/ should be done throughout the license?

>   d. You distribute one of the following with the Derived Work:

[semantic nit] Does it have to be only one?

I suggest: s/one/at least one/

>        1. A complete, unmodified copy of The Work; if your
>        distribution of a modified file is made by offering access to
>        copy the modified file from a designated place, then offering
>        equivalent access to copy The Work from the same place meets
>        this condition, even though third parties are not compelled to
>        copy The Work along with the modified file;

[aside] Does it have to be the "same place"?  To inject technology into
the discussion, if the distributor can point the user to an available
resource (emphasis on "available") where they can get an
MD5-sum-identical copy, isn't that just as good?  A similar issue came
up with Debian and the Knoppix projects recently.  The "same place" may
keep, say, commercial distributors of Derived Works from outsourcing or
subcontracting responsibility for the delivery of parts of the Work that
*weren't* modified.  Also, people could really start splitting hairs
about the meaning of "the same place" when we're talking about network
services.  Does my hypothetical company violate the spirit or letter of
6.d.1. if they use HTTP redirects to send requests for The Work to
another location?  This is an aside, so I raise it to be thought about,
not to say that this clause needs to be rewritten.

>        2. Information that is sufficient to obtain a complete,
>           unmodified copy of The Work.
> 
> 7.  If you are not the Current Maintainer of The Work, you may
> distribute a Compiled Work generated from a Derived Work, as long as
> the Derived Work is distributed to all recipients of the Compiled
> Work, and as long as the conditions of Clause 6, above, are met with
> regards to the Derived Work.

[aside] Hello, copyleft!

> 8.  The conditions above are not intended to prohibit, and hence do
> not apply to, the modification, by any method, of a file so that it
> becomes identical to an  updated version of that file of The Work as
> it is distributed by the Current Maintainer under Clause 4, above.

[semantic nit] File/component dichotomy again; see above.

I suggest: s/file/component/ (but I'm not on fire about it)

> 9.  Distribution of The Work or any Derived Work in a packed format,
> where The Work or that Derived Work (in whole or in part) is generated
> by running some other program on that packed format, does not relax or
> nullify any sections of this license as they pertain to the files that
> are unpacked from the packed format.

[semantic nit] I think use of the term "packed" is unnecessary and
potentially cause for stupid arguments.

I suggest: s/packed //
           s/running some other program on that format/subjecting that
                                                       format to a process/
           s/generated/extracted/
           s/unpacked/extracted/

Or perhaps s/(generated|unpacked)/produced/.

> 10. a. A Derived Work may be distributed under a different license
>        provided that license itself honors the conditions listed
>        in Clause 6 above, in regard to The Work, though it does not
>        have to honor the rest of the conditions in this license.

[aside] This allows people to, for instance, distribute Works under this
license under the GNU GPL as well; am I correct?

>       
>     b. If a Derived Work is distributed under this license, that
>        Derived Work must provide sufficient documentation as part of
>        the itself to allow all recipients of that Derived Work to

[semantic wart] "the itself"?  Do you mean "the Work itself"?

I suggest: s/as part of the itself/to the recipient of the Derived Work/

[semantic wart] I'm pretty sure you don't mean to imply that each
Derived Work distributor has a responsibility to provide such
documentation even to people who received a Derived Work from someone
else.  I.e., no third-party involvement should be compelled.

I suggest: s/all recipients/each recipient/

>        honor the restrictions in Clause 6 above, concerning changes
>        from The Work.
> 
> 11. This license places no restrictions on works that are unrelated to
> The Work, nor does this license place any restrictions on aggregating
> such works with The Work by any means.
> 
> 12.  Nothing in this license is intended to, or may be used to, prevent
> complete compliance by all parties with all applicable laws.

[aside] Whew.  We're on the back stretch now.

> NO WARRANTY
> ===========
> 
> There is no warranty for The Work.  Except when otherwise stated in
> writing, the Copyright Holder provides The Work `as is', without
> warranty of any kind, either expressed or implied, including, but not
> limited to, the implied warranties of merchantability and fitness for
> a particular purpose.  The entire risk as to the quality and performance
> of The Work is with you.  Should The Work prove defective, you
> assume the cost of all necessary servicing, repair, or correction.
> 
> In no event unless agreed to in writing will the Copyright Holder, or
> any author named in the files of The Work, or any other party who may

[semantic nit] Tired old s/files/components/ thing again.

> distribute and/or modify The Work as permitted above, be liable to
> you for damages, including any general, special, incidental or
> consequential damages arising out of any use of The Work or out of
> inability to use The Work (including, but not limited to, loss of
> data, data being rendered inaccurate, or losses sustained by anyone as
> a result of any failure of The Work to operate with any other
> programs), even if the Copyright Holder or said author or said other
> party has been advised of the possibility of such damages.

Argh, I gotta stop here (legalese fatigue, and yes, I know I do more
than my share of causing it in others).  I will follow-up soon with my
comments on the remaining two major sections.

I hope you find the above analysis useful.

-- 
G. Branden Robinson                |    To Republicans, limited government
Debian GNU/Linux                   |    means not assisting people they
branden@debian.org                 |    would sooner see shoveled into mass
http://people.debian.org/~branden/ |    graves.          -- Kenneth R. Kahn

Attachment: pgpgNuFVUMIoZ.pgp
Description: PGP signature


Reply to: