"Fossies" - the Fresh Open Source Software Archive

Member "afio-2.5.2/afio_license_issues_v5.txt" (30 Nov 2018, 36752 Bytes) of package /linux/misc/afio-2.5.2.tgz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    2 Issues with the afio license text identified in 2008
    3 ====================================================
    6 About afio
    7 ==========
    9 Afio is a fault-tolerant archiver/backup tool for Unix systems.  Afio
   10 was created in 1985 by Mark Brukhartz. Since then, many contributers
   11 and maintainers have added features and bug fixes.  Afio is similar to
   12 Unix tools like tar, cpio, star, and pax.  However, as a feature that
   13 these other tools lack: afio has the ability to make compressed
   14 archive files that are very fault tolerant against byte errors.  This
   15 fault tolerant compression has attracted a user base that has been
   16 sufficiently large to keep afio alive as a maintained piece of
   17 software.
   19 Afio project information and link to sources:
   20 http://freshmeat.net/projects/afio/
   22 About this note
   23 ===============
   25 In 2008, several people have raised the question if afio can be
   26 considered 'free' software by modern standards, see for example
   28 https://bugzilla.redhat.com/show_bug.cgi?id=449037
   29 http://spot.livejournal.com/303000.html
   30 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509287
   31 http://www.mail-archive.com/debian-legal@lists.debian.org/index.html#39478
   33 A number of separate issues were raised in these discussions, this
   34 note tries to identify and address all of them.
   36 The answer to the question if afio is free depends partly on the
   37 definition of free.  This note will not try to define the true meaning
   38 of free.  The main goal of this note is to help the reader to
   39 determine if afio is 'free software' or 'open source' or 'freely
   40 distributable' by the definition chosen by the reader.  To meet that
   41 goal, various valid but sometimes contradictory lines of reasoning
   42 about 'free' will be described and discussed.
   44 This note was written by Koen Holtman (the current afio maintainer) in
   45 January/February 2009, based on a review of the discussions on the web
   46 and further e-mail discussions with a number of people.
   48 In this note, the term 'FOSS' is used to refer to the broad class of
   49 free/open/etc software in general.  The term 'Linux distro' is used to
   50 refer to any GNU/Linux distribution.
   52 Disclaimer: the author of this note is not a lawyer, nor does he play
   53 one on TV.
   56 Full afio license text
   57 ======================
   59 The full afio license text (for afio 2.4.6 and later) is reproduced in
   60 this section.
   62 <start>
   63  * afio.c
   64  *
   65  * Manipulate archives and files.
   66  *
   67  * This software was written by Mark Brukhartz at Lachman Associates,
   68  * Inc..  Additional code was written by a large cast of people.
   69  *
   70  * Licensing and (re)distribution
   71  * ------------------------------
   72  *
   75  *
   76  * Because of historical reasons, different parts of this software
   77  * package are covered by different licenses.  However:
   78  *
   79  * A) This software package as a whole may be re-distributed by any
   80  *    method that satisfies the conditions of both the Perl "Artistic
   81  *    License" and the GNU Library General Public License.
   82  *
   83  * B) According to the theory.html file of the Sunsite Archive
   84  *    Maintainers, this implies that the correct LSM template field
   85  *    is:
   86  *
   87  *          Copying-policy: LGPL
   88  *
   89  * C) This software package can also be re-distributed under
   90  *    particular conditions that are _weaker_ than the Perl "Artistic
   91  *    License" combined with the GNU Library General Public License.
   92  *    Redistribution need only satisfy all four license notices below.
   93  *
   94  * Disclaimer: I am not a lawyer, and neither are the Sunsite Archive
   95  * Maintainers.
   96  *
   98  *
   99  * ------------------------------------------------------------------
  100  *
  101  * License notice 1, covering part of this software package.
  102  *
  103  * [Covers the original 1985 afio code]
  104  *
  105  * Copyright (c) 1985 Lachman Associates, Inc..
  106  *
  107  * This software was written by Mark Brukhartz at Lachman Associates,
  108  * Inc.. It may be distributed within the following restrictions:
  109  *	(1) It may not be sold at a profit.
  110  *	(2) This credit and notice must remain intact.
  111  * This software may be distributed with other software by a commercial
  112  * vendor, provided that it is included at no additional charge.
  113  *
  114  *
  115  * [Note: it is believed that condition 5 of the Perl "Artistic
  116  * License" implies the intent of restriction (1) above.]
  117  *
  118  * --------
  119  *
  120  * ** License notice 2, covering part of this software package.
  121  *
  122  * [Covers the tempnam function]
  123  *
  124  * Copyright:	Copyright (c) 1989 by Monty Walls.
  125  *		Not derived from licensed software.
  126  *
  127  *		Permission to copy and/or distribute granted under the
  128  *		following conditions:
  129  *
  130  *		1). This notice must remain intact.
  131  *		2). The author is not responsible for the consequences of use
  132  *			this software, no matter how awful, even if they
  133  *			arise from defects in it.
  134  *		3). Altered version must not be represented as being the
  135  *			original software.
  136  *
  137  * --------
  138  *
  139  * ** License notice 3, covering part of this software package.
  140  *
  141  * [Covers the contents of the gnu.fnmatch.tar.gz file]
  142  *
  143  *  Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
  144  *
  145  *  This library is free software; you can redistribute it and/or
  146  *  modify it under the terms of the GNU Library General Public License as
  147  *  published by the Free Software Foundation; either version 2 of the
  148  *  License, or (at your option) any later version.
  149  *
  150  *  This library is distributed in the hope that it will be useful,
  151  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  153  *  Library General Public License for more details.
  154  *
  155  *  You should have received a copy of the GNU Library General Public
  156  *  License along with this library; see the file COPYING.LIB.  If
  157  *  not, write to the Free Software Foundation, Inc., 675 Mass Ave,
  158  *  Cambridge, MA 02139, USA.
  159  *
  160  * --------
  161  *
  162  * ** License notice 4, covering part of this software package.
  163  *
  164  * [Covers the remainder of this software package]
  165  *
  166  * Additional code was written by a large cast of people.
  167  *
  168  * All additional code may be redistributed under the conditions of
  169  * license notice 1.
  170  *
  171  * Note that the authors of the additional code retain the right to
  172  * allow for the re-distribution of their code under weaker (and less
  173  * exotic) conditions.
  174  *
  175  * --------
  176  *
  178  *
  182  *
  183  *
  184  * [End of licensing and redistribution section]
  185 <end>
  187 The remaining sections of this note address issues raised with this
  188 license.
  190 The most important issue is issue number 2.  Issue number 1 is about
  191 the question: why bother at all?
  194 Issue 1. Why bother distributing afio if there are alternatives
  195 like tar and cpio with a standard OSI/FSF approved free license?
  196 ================================================================
  198 - Issue 1 description
  200 The afio license is not a standard OSI/FSF approved free license, in
  201 fact it includes text written in 1985 that is widely considered to be
  202 problematic.
  204 There are several tools, with arguably better licenses, that are
  205 similar to afio, e.g.
  207  gnu tar (GPL v3)
  208  gnu cpio (GPL v3)
  209  star (CDDL+GPL, though there seem to be some disputes about license
  210   compatibility)
  211  heirloom cpio/pax (free license)
  212  pax from Keith Muller
  214 So would it not be a good thing to remove afio from a Linux distro?
  215 Removal would make a) the license situation of the distro more
  216 easy/pure while b) not removing any functions people need.
  218 - Response to issue 1
  220 1) Utility argument
  222 The above mentioned alternatives to afio do not provide everything
  223 that afio provides, so removing it from a Linux distro would decrease
  224 the utility of the distro.  Some users of the distro will miss it if
  225 it is taken out.
  227 afio has one unique feature (fault tolerant compressed archives) that
  228 all of the above lack.  Also, it has several specialized options that
  229 the other tools lack, and there are deployed backup scripts that rely
  230 on these specialized options.  Afio is also very mature (bug-free) and
  231 portable because of its age and user base.  The user base includes
  232 power users backing up large and complex filesystems, and these power
  233 users have historically found and fixed very obscure bugs.  This
  234 maturity of afio is a big advantage in a backup tool -- a
  235 written-from-scratch replacement would take a long time to be equally
  236 mature.
  238 Several FOSS backup packages support afio as an archive engine, and
  239 some were designed specifically around afio.
  241 2) Community/historical argument
  243 Afio is a FOSS project that started in 1985 and has grown 4-fold in
  244 code size and features since.  Including afio into a distro shows to
  245 potential FOSS contributers just how long such software can remain
  246 useful, and celebrates the continuity between the current Web based
  247 FOSS community with the historical UNIX/USENET news based FOSS
  248 community.
  251 Issue 2. License places limits on redistribution by some parties
  252 ================================================================
  254 - Issue 2 description
  256 Several definitions of 'free' software include the requirement that
  257 any party should be able to re-distribute it.  For example.  Debian
  258 Free Software Guideline 1 (DFSG#1) states:
  260   The license of a Debian component may not restrict any party from
  261   selling or giving away the software as a component of an aggregate
  262   software distribution containing programs from several different
  263   sources. [...]
  265 (See: http://www.debian.org/social_contract.en.html )
  267 The following part of the afio license can be read to contradict this:
  269  * This software was written by Mark Brukhartz at Lachman Associates,
  270  * Inc.. It may be distributed within the following restrictions:
  271  *	(1) It may not be sold at a profit.
  272  *	(2) [...]
  273  * This software may be distributed with other software by a commercial
  274  * vendor, provided that it is included at no additional charge.
  276 The problem is that the last two lines of the above text do allow the
  277 'selling or giving away the software as a component of an aggregate
  278 software distribution', but they ONLY allow this, when the selling is
  279 at a profit, if you are a 'commercial vendor'.  So for example a
  280 private individual, who cannot be considered a commercial vendor,
  281 would be prevented by this license from burning and re-selling a CD
  282 including afio at a profit.  Therefore the license restricts some
  283 parties from re-distribution, violating DFSG#1 and also DFSG#5, making
  284 afio non-free.
  286 - Response to issue 2
  288 The above interpretation of the license text is a possible one, but it
  289 is not the only possible interpretation.  If one wants to make a case
  290 for afio satisfying DFSG#1, then one has to argue that the designation
  291 'commercial vendor' designates very broadly ANY party that is engaged
  292 in 'selling at a profit'.
  294 A private individual re-selling a CD including afio at a profit could
  295 claim to be acting as a 'commercial vendor' as far as the meaning of
  296 the license text is concerned.  Is such a claim credible?  I believe
  297 it is.
  299 Below are the two arguments why 'commercial vendor' covers any party
  300 selling at a profit.
  302 1) Argument by authority of the author
  304 We managed to contact Mark Brukhartz, and after discussion of the
  305 issues he provided a statement on the meaning of the license text that
  306 he wrote.  The text is:
  308  * This software was written by Mark Brukhartz at Lachman Associates,
  309  * Inc.. It may be distributed within the following restrictions:
  310  *	(1) It may not be sold at a profit.
  311  *	(2) [...]
  312  * This software may be distributed with other software by a commercial
  313  * vendor, provided that it is included at no additional charge.
  315 Here is the statement from Mark on this license text:
  317   It's my opinion, as the sole author of the license, that it does not
  318   restrict any party from selling or giving away the software as a
  319   component of an aggregate software distribution containing programs
  320   from several different sources.  Clause (1) allows the giving away
  321   of the software and the selling at no profit.  The text 'This
  322   software may be distributed with other software by a commercial
  323   vendor, provided that it is included at no additional charge' should
  324   be read as granting the additional right to sell at profit the
  325   software as part of an aggregate distribution -- the term
  326   'commercial vendor' was written to mean, and should be read to mean,
  327   'any seller who aims to make a profit'.
  329 If should be pretty clear that Mark believes that the license
  330 satisfies DFSG#1 and DFSG#5.
  332 I should caution the reader that this statement by Mark does not
  333 fully resolve the interpretation issue: theoretically a judge might
  334 disagree with Mark, and a judge is allowed to have the final
  335 say. Also, Mark is not the legal owner of the license: Lachman
  336 Associates owned the copyright and therefore the license, but Lachman
  337 and its intellectual property was later sold to another company, and
  338 it is in fact not clear which company owns the copyright to Mark's
  339 code right now, see this link:
  341   http://spot.livejournal.com/303000.html
  343 Also, after Mark wrote and licensed the original code, the afio code
  344 base has grown by a factor of 4, so some other contributers (who
  345 retain ownership of the copyrights to their own code) could
  346 potentially speak up to object to Mark's opinion.  Nevertheless, as
  347 Mark was the sole author of the license text in question, his opinion
  348 on the interpretation of the text does carry significant weight.
  350 2) Argument that a broad interpretation of the meaning of 'commercial
  351 vendor' is possible and most likely
  353 If we look up 'commercial vendor' in the dictionary
  354 (http://www.thefreedictionary.com/), we find:
  356   vendor [..]
  357     1. One that sells or vends: a street vendor; a vendor of software
  358        products on the Web.
  359     2. [...]
  360   [...]
  362  commercial [...]
  363    [...]
  364    3. Having profit as a chief aim [...]
  366 So it is perfectly valid to read 'commercial vendor' as broadly 'one
  367 that sells with profit as a chief aim', meaning 'anybody who sells at
  368 a profit'.  It is not necessary to narrowly read 'commercial vendor'
  369 as 'a real company as opposed to a private individual'.
  371 Also speaking for the broad interpretation is the fact that the words
  372 'it may not be sold at a profit' were used a few lines earlier in the
  373 license text.  It is very plausible that the term 'commercial vendor'
  374 was used by the author as a short-hand to designate anyone doing the
  375 opposite of 'it may not be sold at a profit'.
  378 - Cautionary statement about the above two arguments
  380 It should be stressed that the above arguments about the broad
  381 interpretation of 'commercial vendor' are not 100.00% 'safe' in a
  382 legal sense.  Any trained lawyer will immediately see that there is
  383 some ambiguity in the afio license text, and that this ambiguity
  384 leaves enough room for a judge to disagree with the above arguments on
  385 why 'commercial vendor' should be interpreted broadly.  Therefore,
  386 anybody acting as if these arguments were true runs the risk of facing
  387 a judge who might not agree.  One of the jobs of a trained lawyer is
  388 to identify such legal ambiguities and to deal with them -- by having
  389 their client stop taking the risk, or by seeking out the license owner
  390 to obtain a clarification that removes the ambiguity.  Unfortunately,
  391 contacting the license owner is not really possible in the case of
  392 afio, see issue #4 below.
  394 So we are left with the following cautionary statement: even though I
  395 believe that the arguments above are very convincing, you will be
  396 taking a legal risk if you re-distribute afio.  I believe it is a very
  397 small risk.  I believe that, if you are a distributer even a very
  398 'pure' version of GNU/Linux, you are already engaged in taking
  399 comparatively larger legal risks.  Somewhat credible parties have
  400 stated that the Linux kernel infringes on patents that have never been
  401 licensed for general use.  In most countries, any distributer of the
  402 Linux kernel therefore runs the legal risk of being sued for patent
  403 infringement.
  406 Issue 3. License does not permit modification
  407 =============================================
  409 - Issue 3 description
  411 Debian Free Software Guideline 3 (DFSG#3) states:
  413   The license must allow modifications and derived works, and must
  414   allow them to be distributed under the same terms as the license of
  415   the original software.
  417 The afio license notices (except for notice 3 which is the LGPL) do
  418 not contain any explicit statement allowing modification, or
  419 re-distribution of modified works.  So afio fails the test of DFSG#3
  420 and cannot be called free software.
  422 - Response to issue 3
  424 Under most versions of copyright law, the default situation is that
  425 original author has the sole right of making copies, and also the sole
  426 right of making modified copies.  So the absence of an explicit
  427 statement in which the author also grants this right to others is
  428 indeed cause for concern.
  430 So we have to ask ourselves: did the copyright holders of afio in fact
  431 grant the right to modify their work to others?  I believe they did,
  432 so afio does satisfy DFSG#3.  I have 2 arguments why they did.
  434 1) Argument by the contents of the license notices
  436 If we look at the 4 license notices, we see that
  438 - notice 1 contains the statement
  440    It may be distributed within the following restrictions:
  441    [...] (2) This credit and notice must remain intact.
  443 - notice 2 contains the statement
  445    Permission to copy and/or distribute granted under the
  446    following conditions:
  447    1). This notice must remain intact. [...]
  449 - notice 3 is the LGPL, which explicitly allows modification
  451 - notice 4 refers to the conditions of notice 1.
  453 So in fact notice 1, 2, and 4 all contain the clause 'this notice must
  454 remain intact'.  Such a clause can be read to imply that 'it is not a
  455 condition that the parts of this work outside of this notice remain
  456 intact'.  By explicitly forbidding the modification of the notice,
  457 they license owners are implicitly allowing the modification of other
  458 parts of the work.  Had they wished to forbid such modifications of
  459 the rest of the work, they would have written different license
  460 notices.
  462 2) Argument by implied licensing
  464 Implied licensing is a legal principle by which a copyright owner can
  465 be said to have granted a license for a certain type of use
  466 implicitly, by their actions, as opposed to explicitly, by writing a
  467 clause in a license text.  See for example:
  469 http://en.wikipedia.org/wiki/Implied_license
  470 http://www.iplawobserver.com/2008/09/implied-license-to-use-custom-created.html
  472 The principle of implied licensing contradicts, to some extent, the
  473 principle in international copyright law that all rights about which
  474 an author remains silent are automatically assigned to the author
  475 only, see
  477 http://en.wikipedia.org/wiki/Copyrights#Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works
  479 There is a growing body of (US) case law supporting implied licensing.
  480 The most interesting part of case law for afio is the court opinion in
  481 Field v. Google, linked from these pages:
  483 http://www.iplawobserver.com/2006/03/googles-cache-was-fair-use-according.html
  484 http://en.wikipedia.org/wiki/Field_v._Google#Implied_License
  486 In this case, Field created a public web page and then objected to
  487 this web page being available in the Google cache.  Google argued,
  488 among other things, that they had an implied license to make the page
  489 available via the Google cache.  The court described implied license
  490 as follows:
  492   A license is a defense to a claim of copyright infringement. [...] A
  493   copyright owner may grant a nonexclusive license expressly or
  494   impliedly through conduct. [...] An implied license can be found
  495   where the copyright holder engages in conduct from which [the] other
  496   [party] may properly infer that the owner consents to his use.
  497   [...] Consent to use the copyrighted work need not be manifested
  498   verbally and may be inferred based on silence where the copyright
  499   holder knows of the use and encourages it.
  501 The court found it significant that Field knew in advance that Google
  502 would be caching his page unless he took some actions in labeling his
  503 web site to prevent it, and that he chose not to take those actions --
  504 Field remained silent thereby granting implied license.  If we look at
  505 the case of afio, we can build an argument for the granting of implied
  506 license as follows.
  508 A. Mark Brukhartz, an employee of the license holder at the time,
  509    posted the afio source code, including an explicit license
  510    statement, to comp.sources.unix in 1987.  Link:
  512      http://groups.google.com/group/comp.sources.unix/browse_thread/thread/ce3312137ad92a37/ec49f37f3e59a267?lnk=gst&q=afio#ec49f37f3e59a267
  514 B. The explicit license text was silent on limiting the right to
  515    modify the code.  To show that there was an implicit license of to
  516    modify the code, we have to show that modification was one of the
  517    uses that the license holder could have expected after posting the
  518    code to comp.sources.unix.
  520 C. The comp.sources community was an early FOSS community, and people
  521    extending other people's code was one of the things that could be
  522    expected in that community. Indeed the creation of such extensions
  523    happened almost immediately in the case of afio -- see D. and
  524    E. below.
  526 D. The above newsgroup archive link shows that after Mark submitted
  527    the sources of afio to the newsgroup, Rich Salz, the moderator of
  528    the newsgroup, added a Makefile to the sources before forwarding
  529    them to the group, thereby in fact distributing a modified version
  530    of afio.  It was common practice for Rich Salz to add a Makefile
  531    when submitted sources did not have them; the license holder would
  532    probably have known this -- and took no steps to forbid it.
  534 E. Mark did not explicitly object when modifications to afio were
  535    posted.  For example, three days after the afio post to
  536    comp.sources.unix, Karl Denniger posted an improvement for afio to
  537    comp.sources.d (an unmoderated companion newsgroup to
  538    comp.sources.unix), with the description:
  540       These are context diffs to the 'afio' program, a cpio
  541       replacement, that was posted recently.  The changes here take
  542       care of what I saw as a possible 1gaffe in the '-y' and '-Y'
  543       options.
  545    Link: http://groups.google.com/group/comp.sources.d/browse_thread/thread/381df257b583954e
  547 F. The license holder knew that it was common practice to modify code
  548    posted to comp.sources.unix. To illustrate that Lachman Associates
  549    would have been well aware of the practice of extending software
  550    tools in the context of the comp.sources newsgroups: in 1989, two
  551    Lachman employees greatly extended a terminal emulator program
  552    written by someone else in 1986, and posted their extended version
  553    to comp.sources.atari.st, see:
  555     http://groups.google.com/group/comp.sources.atari.st/msg/95d006760c056af1
  558 Given all of the above, it can be argued that the actions of Mark
  559 (while he identified himself as working for the license owner Lachman
  560 Associates) constituted the granting of an implied license to modify
  561 afio.
  563 The current version of afio contains many contributions by other
  564 people than Mark, and these contributors typically did not add any
  565 license texts of their own. For these contributions, similar arguments
  566 for the granting of implied license to modify can be made.
  568 Note that the principle of implied licensing has been developed mostly
  569 through recent US case law; as far as I know it is still absent from
  570 international treaties.  So in some locations, invoking this principle
  571 will be legally more risky than in other locations.  A trained legal
  572 person would prefer to avoid a reliance on implied licensing whenever
  573 possible.
  576 Issue 4. Afio should be re-licensed under a better license
  577 ==========================================================
  579 - Issue 4 description
  581 Various software packages which had problematic licenses have now been
  582 re-licensed under better licenses.  Often they have been re-licensed
  583 under OSI/FSF approved licenses.  The same should be done with afio.
  585 - Response to issue 4
  587 It would be nice if re-licensing of afio were possible, but it is not
  588 possible in practice.
  590 Afio, in the current 2.5 version, is not the in-house product of a
  591 single company.  In the 22 years since Mark Brukhartz posted afio to
  592 comp.sources.unix, the FOSS community has added many features which
  593 have made the package grow by a factor of 4.  Several authors have
  594 contributed major pieces of code to afio, and many more contributers
  595 (an estimated 40-100 people) provided patches, ideas, and example
  596 scripts.  The afio sources do not contain complete log files
  597 containing the names of all contributers, so contacting all of them,
  598 which would be required by copyright law in order to re-license afio,
  599 is a virtually impossible task.  Furthermore, as mentioned above, Mark
  600 Brukhartz is not the owner of the copyright of the original afio code,
  601 Lachman Associates owned this copyright, and it is unclear which
  602 company owns it now (see http://spot.livejournal.com/303000.html).
  603 That company would have to be identified and would have to be willing
  604 to re-license.
  606 As an alternative to re-licensing ALL afio code, it would be possible
  607 to try to find a subset of the contributers and ask them to re-license
  608 their own contributed code.  Depending on the success in finding the
  609 contributers, this could (according an the estimate of the current
  610 maintainer) bring about 30-60% of the afio code base under a new
  611 license. However, but such an action would not satisfy those seeking
  612 legal clarity on the status of afio as a whole.
  614 Some software projects have managed to improve their license situation
  615 by re-writing from scratch those parts of the code that had
  616 questionable or unknown licenses.  However, for afio this would mean
  617 rewriting 30-70% of the code.  Any such re-write would introduce a lot
  618 of new bugs, which is not desirable in a mature backup tool.
  621 Issue 5. What about the Copying-policy: LGPL thing in the license text?
  622 =======================================================================
  624 - Issue 5 description
  626 The license text includes at the start a summary
  631 and this summary text  explains how
  633  *          Copying-policy: LGPL
  635 is the right LSM template value for afio.
  637 The writing of this summary information has been interpreted by some
  638 sources as an attempt to re-license afio under the LGPL, see
  639 e.g. http://spot.livejournal.com/303000.html.
  641 So one might ask: is this summary information an attempt a
  642 re-licensing, and if not, why is it there?
  644 - Response to issue 5
  646 (Response written by Koen Holtman, author of the SUMMARY INFORMATION
  647 in question, partly based on personal recollections)
  649 The summary information is definitely not an attempt at relicensing. A
  650 close reading should make this clear.
  652 The summary information was added to afio in November 1999, it was
  653 prompted by the fact that the sunsite/ibiblio/metalab FTP site robots
  654 at that time stopped accepting random strings Copying-policy field of
  655 the .lsm file.  (.lsm is a metadata file format for describing FOSS
  656 software packages on FTP sites) The FTP site robots only accepted
  657 certain fixed strings like 'LGPL'.  See the following web page:
  659 http://web.archive.org/web/20001117112300/http://www.ibiblio.org/pub/Linux/LICENSES/theory.html
  661 The LGPL label was chosen by Koen Holtman among the possible fixed
  662 strings based on the contents of the web page above.  Note that the
  663 Perl Artistic license referred to at the time was the 'original' Perl
  664 artistic license of 1997 which contains the following text:
  666    You may charge a reasonable copying fee for any distribution of
  667    this Package. You may charge any fee you choose for support of this
  668    Package. You may not charge a fee for this Package itself.
  670 Several people have since argued that part of the Artistic license
  671 text has problems, and a new version of the Artistic license (v2.0)
  672 was written that excludes this text.
  674 In an interesting twist, the site freshmeat.net at one point seems to
  675 have imported the computer-readable .lsm file of afio, using the
  676 Copying-policy line to create a 'license' line on the web site:
  678  [License] OSI Approved :: GNU Lesser General Public License (LGPL)
  680 (see http://web.archive.org/web/20070930211041/http://freshmeat.net/projects/afio/ )
  682 So the interaction between the sunsite and freshmeat automatic robots
  683 seems to have effectively 'laundered' the complex license status of
  684 afio.  Then, the FSF seems to have copied the data from Freshmeat:
  686 http://web.archive.org/web/20080109010049/http://directory.fsf.org/project/afio/
  687 Both these directories have since been corrected.
  690 Issue 6.  Several people working for/with FOSS related
  691 organizations have called afio not-free.
  692 =======================================================
  694 - Issue 6 description
  696 In his blog post at http://spot.livejournal.com/303000.html , Tom
  697 Callaway, who works on Fedora legal issues, quoted the 1985 part of
  698 the afio license and wrote:
  700    Now, this license isn't free.
  702 Tom then goes on point out that the main problem with the license is
  703 with the 'It may not be sold at a profit.' clause, i.e. issue 2 above.
  705 At https://bugzilla.redhat.com/show_bug.cgi?id=449037, similar
  706 conclusions are drawn, and the issue of including afio in Fedora is
  707 closed as 'cannot fix'.
  709 In response to issues raised by Tom Callaway, the FSF reviewed the
  710 afio license and removed afio from it's Free Software directory.  (See
  711 a note by Brett Smith in the comment track at
  712 http://spot.livejournal.com/303000.html.)  This removal means that the
  713 FSF determined that the afio license is non-free by FSF standards.
  715 So it seems like expert opinion is going against the idea that afio
  716 is free.
  718 - Response to issue 6
  720 Are the experts above wrong?  I believe that they have made no logical
  721 errors in their reasoning -- it looks like they correctly applied a
  722 set of rules to determine freeness.  So if we are to make a case for
  723 afio being 'free' by some definitions, we are down to examining the
  724 rules that were applied, and showing that at least one of them is not
  725 included in all possible definitions of 'free'.
  727 In the discussions in the links above, we find that the people
  728 involved, in so far as they explain their reasoning, are referring to
  729 the same definitions of 'free' I have used in this note, e.g.  Debian
  730 Free Software Guideline #1.  However, the conclusions about freeness
  731 drawn are generally more negative than my conclusions in this note.
  732 Why?
  734 I believe that the people in the links above are all using the
  735 following rule when applying guidelines for freeness:
  737  worst-case-rule: If the license text is ambiguous, in a way that would
  738  leave enough room for a judge to disagree that the license meets our
  739  written definition of 'free', then the license should be treated as
  740  non-free.
  742 In my own analysis of the legal issues above, I have avoided applying
  743 this worst-case-rule by default.  I have however tried to identify all
  744 possible places where this worst-case-rule could be applied.
  746 It is very common for trained lawyers to apply this worst-case-rule,
  747 to go by the worst possible interpretation of an ambiguous legal text.
  748 In fact, in a multidisciplinary business team, one of the key skills
  749 that a lawyer is expected to bring to the table is the skill to find
  750 the legal ambiguities and worst-cases.
  752 In the FOSS context, the worst-case-rule has often been used when a
  753 large company (e.g. Netscape, Sun, Microsoft) created a specialized
  754 license to go with a specific piece of software that the company
  755 wanted to share with or contribute to the FOSS community.  Arguably,
  756 it is a good strategy in such a case for the FOSS community to assume
  757 the worst possible interpretation of the license text concerned.  The
  758 use of the worst-case-rule has sometimes led to companies improving
  759 their license texts from a FOSS community point of view.
  761 However, I would argue that applying this worst-case-rule to afio, a
  762 historical product of the FOSS community for which the license text
  763 cannot be changed anymore, is like throwing out the baby with the
  764 bathwater.  There is no need to treat afio as if it might be a
  765 carefully constructed Trojan horse.
  767 So I feel that applying the worst-case-rule is fine in come cases, but
  768 destructive in others.  Does this mean that I am arguing for a double
  769 standard as far as the legal analysis of FOSS licenses is concerned?
  770 I am not -- in the end, a legal analysis is a determination of the
  771 risk of getting sued and of losing in court when one is sued.  This
  772 risk cannot be determined correctly by doing a narrow analysis of the
  773 license text under the worst-case assumption that the other party is
  774 out to get you.  Other factors, like those considered for afio in this
  775 note, should also play a role in legal risk determination.
  777 I believe that a strict application of the worst-case-rule, when
  778 judging a software package against e.g. the Debian Free Software
  779 Guidelines or the four kinds of software freedoms defined by the FSF,
  780 will lead to results that are counter-productive for the FOSS
  781 community:
  783   - The worst-case-rule will lead to a favoring of software packages
  784     released in one go by a single company over almost all software
  785     packages that were grown over many years by volunteer contributors
  786     using the Internet.  Most volunteer software will look worse
  787     through the lens of the worst-case-rule, because of the way
  788     copyright law works.  In a worst-case legal analysis, copyright
  789     law requires that all volunteer contributers have made explicit
  790     statements placing their contributions under a free license.  If
  791     one such statement is missing, then there exists an ambiguity in
  792     that author's wishers, that has to be interpreted by the
  793     worst-case-rule as a lack of permission to copy or modify.
  795   - Living with the worst-case-rule in a FOSS project will raise
  796     barriers of entry for contributers to FOSS projects, because these
  797     contributers would have to be asked to make legal statements
  798     licensing their contributions, instead of relying on the principle
  799     of implicit license.
  801   - The worst-case-rule will favor software projects that were started
  802     recently over some longer-running software projects, because only
  803     the recent projects could start with license texts that have been
  804     constructed to be unambiguous according to the most recent legal
  805     insights.
  807 In conclusion, I believe that the reason why the experts in the links
  808 above found afio to be non-free is that they all implicitly or
  809 explicitly applied the worst-case-rule.
  811 I do not want to argue that the worst-case-rule should never be
  812 applied.  In fact, a Linux distro based on the strict application of
  813 the worst-case-rule could be considered valuable by some, and some
  814 distributions that are looking to be '100% free' seem to be applying
  815 this rule.  Note that '100% free' according to the worst-case-rule
  816 does not mean '100% elimination of all legal risks to the user'.  No
  817 Linux distro can be 100% pure in this way: the kernel alone comes with
  818 patent risks.
  820 I believe that the worst-case-rule should not be used by more general
  821 Linux distros, unless it is combined with a moderating principle.
  822 Without a moderating principle, the worst-case-rule has negative
  823 effects on the community aspects of FOSS.
  825 Conclusion
  826 ==========
  828 This note has addressed several questions that have been raised on the
  829 status of afio as 'free' software.
  831 The best argument for afio being 'non-free' is that the afio license
  832 text that was written in 1985 fails the test of the worst-case-rule:
  833 the text is ambiguous in a way that would leave enough room for a
  834 judge to disagree that the license meets e.g. Debian Free Software
  835 Guideline 1.
  837 The best argument for afio being 'free' is that the worst-case rule
  838 should not be applied in the case of afio, because it is the product
  839 of a long-running FOSS effort, and because the ambiguities in the 1985
  840 license text, when examined in context, do not create any practical
  841 barriers against exercising the freedoms that a modern FOSS user or
  842 distributer expects to have.  I believe that legally speaking, if a
  843 user, programmer, or distributer treats afio as 'free' software, the
  844 risk of having a court conclude that they are in violation of the afio
  845 license is very low, low enough to be lost in the background noise.
  847 It is not always morally right to treat copyrighted works in a 'free'
  848 way, just because the legal risks of doing so are low.  But in the
  849 case of afio I believe treating it as 'free' it is definitely morally
  850 right, because this what the authors intended.
  853 <end of note>