"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
the uninterpreted source code file.
2 Issues with the afio license text identified in 2008
6 About afio
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
19 Afio project information and link to sources:
22 About this note
25 In 2008, several people have raised the question if afio can be
26 considered 'free' software by modern standards, see for example
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
59 The full afio license text (for afio 2.4.6 and later) is reproduced in
60 this section.
63 * afio.c
65 * Manipulate archives and files.
67 * This software was written by Mark Brukhartz at Lachman Associates,
68 * Inc.. Additional code was written by a large cast of people.
70 * Licensing and (re)distribution
71 * ------------------------------
73 * THE SUMMARY INFORMATION BELOW WAS WRITTEN FOR THE BENEFIT OF
74 * SOFTWARE DISTRIBUTORS
76 * Because of historical reasons, different parts of this software
77 * package are covered by different licenses. However:
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.
83 * B) According to the theory.html file of the Sunsite Archive
84 * Maintainers, this implies that the correct LSM template field
85 * is:
87 * Copying-policy: LGPL
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.
94 * Disclaimer: I am not a lawyer, and neither are the Sunsite Archive
95 * Maintainers.
97 * END OF SUMMARY INFORMATION
99 * ------------------------------------------------------------------
101 * License notice 1, covering part of this software package.
103 * [Covers the original 1985 afio code]
105 * Copyright (c) 1985 Lachman Associates, Inc..
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.
115 * [Note: it is believed that condition 5 of the Perl "Artistic
116 * License" implies the intent of restriction (1) above.]
118 * --------
120 * ** License notice 2, covering part of this software package.
122 * [Covers the tempnam function]
124 * Copyright: Copyright (c) 1989 by Monty Walls.
125 * Not derived from licensed software.
127 * Permission to copy and/or distribute granted under the
128 * following conditions:
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.
137 * --------
139 * ** License notice 3, covering part of this software package.
141 * [Covers the contents of the gnu.fnmatch.tar.gz file]
143 * Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
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.
150 * This library is distributed in the hope that it will be useful,
151 * but WITHOUT ANY WARRANTY; without even the implied warranty of
152 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
153 * Library General Public License for more details.
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.
160 * --------
162 * ** License notice 4, covering part of this software package.
164 * [Covers the remainder of this software package]
166 * Additional code was written by a large cast of people.
168 * All additional code may be redistributed under the conditions of
169 * license notice 1.
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.
175 * --------
177 * ** WARRANTY NOTICE
179 * THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
180 * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
181 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
184 * [End of licensing and redistribution section]
187 The remaining sections of this note address issues raised with this
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?
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
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
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
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
251 Issue 2. License places limits on redistribution by some parties
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:
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. [...]
362 commercial [...]
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
406 Issue 3. License does not permit modification
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
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:
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
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:
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:
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'
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:
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
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
576 Issue 4. Afio should be re-licensed under a better license
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?
624 - Issue 5 description
626 The license text includes at the start a summary
628 * THE SUMMARY INFORMATION BELOW WAS WRITTEN FOR THE BENEFIT OF
629 * SOFTWARE DISTRIBUTORS
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:
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:
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.
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.
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
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
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
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.
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>