Bug 449037 (afio)

Bruno, please include a Spec URL so we can do an initial glance at the .spec
file without downloading the full SRPM.  Thanks.

I agree with Kyle that its easier on the reviewers if you don't require them to
download and unpack your src.rpm to take a quick look at your spec.  I guess it
depends on how much you really want to have your software reviewed.

Now, I did unpack and build it.  First, the rpmlint output:
  W: spurious-executable-perm /usr/share/man/man1/afio.1.gz
There's no reason for the manpage to be executable.

  W: spurious-executable-perm /usr/share/doc/afio-2.5/script2/restore
  W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/gnupg_read
  W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/pgp_read
  W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/pgp_write
  W: spurious-executable-perm /usr/share/doc/afio-2.5/script4/tapechange
  W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/gnupg_write
  W: spurious-executable-perm /usr/share/doc/afio-2.5/script2/backup
It's not necessarily a blocker for documentation to be executable, but you
should consider whether you expect that anyone will need to call those scripts,
because you shouldn't expect people to have to run things out of /usr/share/doc.

  W: invalid-license GPL
Please read http://fedoraproject.org/wiki/Licensing and choose an appropriate
License: tag.

  W: doc-file-dependency /usr/share/doc/afio-2.5/script2/backup /bin/bash
This shouldn't be an issue if those scripts actually belong in the
documentation.  We will avoid the case that documentation brings in significant
additional dependencies, but bash isn't problematic.

Other comments:
Please be consistent in macro use in the spec; if you're going to use "%{__rm}"
then you need to use "%{__mkdir}", "%{__mkdir_p}", "%{__install}", etc.  Or you
can just use the non-macro versions throughout and save the typing.  It's up to
you, but you must be consistent.

You must not hardcode ".fc9".  Please use the %{dist} tag appropriately:
http://fedoraproject.org/wiki/Packaging/DistTag

Is ftp.project-builder.org really the canonical upstream for the source?  It
seems like the URL you provide doesn't point to that site at all.

(In reply to comment #2)
> I agree with Kyle that its easier on the reviewers if you don't require them to
> download and unpack your src.rpm to take a quick look at your spec.  I guess it
> depends on how much you really want to have your software reviewed.

First sorry for the fact I didn't answer to Kyle. I just didn't receive a mail
warning me of his answer :-(. I have no problem providing the .spec file of course.

> Now, I did unpack and build it.  First, the rpmlint output:
>   W: spurious-executable-perm /usr/share/man/man1/afio.1.gz
> There's no reason for the manpage to be executable.

Yep. Fixed.

>   W: spurious-executable-perm /usr/share/doc/afio-2.5/script2/restore
>   W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/gnupg_read
>   W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/pgp_read
>   W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/pgp_write
>   W: spurious-executable-perm /usr/share/doc/afio-2.5/script4/tapechange
>   W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/gnupg_write
>   W: spurious-executable-perm /usr/share/doc/afio-2.5/script2/backup
> It's not necessarily a blocker for documentation to be executable, but you
> should consider whether you expect that anyone will need to call those scripts,
> because you shouldn't expect people to have to run things out of /usr/share/doc.

In fact those are set up by the upstream make install procedure because those
are scripts given as example. That way you just have to copy them to be able to
use them. Let me know if you think It would be better to change that in the spec
file.

>   W: invalid-license GPL
> Please read http://fedoraproject.org/wiki/Licensing and choose an appropriate
> License: tag.

Oops. More over it's LGPL in fact. So used LGPLv2+

>   W: doc-file-dependency /usr/share/doc/afio-2.5/script2/backup /bin/bash
> This shouldn't be an issue if those scripts actually belong in the
> documentation.  We will avoid the case that documentation brings in significant
> additional dependencies, but bash isn't problematic.

So I think I can let it like that ?

> Other comments:
> Please be consistent in macro use in the spec; if you're going to use "%{__rm}"
> then you need to use "%{__mkdir}", "%{__mkdir_p}", "%{__install}", etc.  Or you
> can just use the non-macro versions throughout and save the typing.  It's up to
> you, but you must be consistent.

Ok I remove the %{__rm} and use rm

> You must not hardcode ".fc9".  Please use the %{dist} tag appropriately:
> http://fedoraproject.org/wiki/Packaging/DistTag

Ok, done.

> Is ftp.project-builder.org really the canonical upstream for the source?  It
> seems like the URL you provide doesn't point to that site at all.

The canonical upstream is what is mentioned in the Url: tag
Should I also use it for the Source: tag (I used the place where I store a copy
alongside the packages I made).

Thanks for your help.
Newet build is at the same place, + spec file:
ftp://ftp.mondorescue.org/test/fedora/9/afio-2.5-1.fc9.src.rpm
ftp://ftp.mondorescue.org/test/fedora/9/afio.spec

Created attachment 313898 [details]
Patch to fix warnings and deprecated code.

MUST Items: 

xx - rpmlint is unclean on RPM
    + [rishi@freebook x86_64]$ rpmlint afio-2.5-1.fc9.x86_64.rpm 
      afio.x86_64: W: spurious-executable-perm /usr/share/doc/afio-2.5/script2/restore
      afio.x86_64: W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/gnupg_read
      afio.x86_64: W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/pgp_read
      afio.x86_64: W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/pgp_write
      afio.x86_64: W: spurious-executable-perm /usr/share/doc/afio-2.5/script4/tapechange
      afio.x86_64: W: spurious-executable-perm /usr/share/doc/afio-2.5/script3/gnupg_write
      afio.x86_64: W: spurious-executable-perm /usr/share/doc/afio-2.5/script2/backup
      afio.x86_64: W: doc-file-dependency /usr/share/doc/afio-2.5/script2/backup /bin/bash
      [rishi@freebook x86_64]$ 

OK - follows Naming Guidelines
OK - spec file is named as %{name}.spec

xx - package does not meet Packaging Guidelines
    + Broken Source tag. Use the URL publised by upstream:
      http://freshmeat.net/redir/afio/144/url_tgz/afio-2.5.tgz
    + The description should be slightly more verbose than the summary. See
      https://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description
      You can consider using the following paragraph from the README file:
      "Afio makes cpio-format archives.  It deals somewhat gracefully with
      input data corruption.  Supports multi-volume archives during
      interactive operation.  Afio can make compressed archives that are
      much safer than compressed tar or cpio archives.  Afio is best used as
      an `archive engine' in a backup script."
    + It might be a good idea to add a check stanza and run 'make regtest' and
      'make regtest2gb' in it.
    + According to
      https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps you
      should use 'install -p'.
    + The ANNOUNCE-2.5 file contains useful information. It should be added to
      %doc in the %files stanza.
    + The ChangeLog file contains no useful information. It should not be
      distributed.
    + According to
      https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation the
      INSTALLATION file should not be distributed.
    + The Dist tag (ie. fc9) should not be a part of the %changelog entry. See
      https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

OK - license meets Licensing Guidelines

?? - License field meets actual license
    + The header in afio.c says:
      "This software package can also be re-distributed under
      particular conditions that are _weaker_ than the Perl "Artistic
      License" combined with the GNU Library General Public License.
      Redistribution need only satisfy all four license notices below."
      I am not sure how this might affect the License tag. Need to verify.

OK - upstream license file included in %doc
    + The perl.artistic.license file might need to be distributed.

OK - spec file uses American English

OK - spec file is legible
    + You might want to split the %doc in multiple lines to achieve the 72/80
      character rule. But it is a matter of style and upto you.

xx - sources match upstream sources
    + The MD5SUM does not match.
      Tarball found in SRPM:
      70fd825bd8af83473eb52d140df84cc3 
      Upstream sources from
      http://freshmeat.net/redir/afio/144/url_tgz/afio-2.5.tgz:
      8c6665e0f875dcd8e1bdb18644b59688

OK - package builds successfully
    + You could consider using the attached patch to fix warnings and
      deprecated code.
      Getting the patch upstream should be the final goal.

OK - ExcludeArch not needed
OK - build dependencies correctly listed
OK - no locales
OK - no shared libraries
OK - package is not relocatable
OK - file and directory ownership
OK - no duplicates in %file

xx - file permissions set properly
    + The scripts in %doc should not have their executable bits set.
    + The preferred attribute definition is: %defattr(-,root,root,-)

OK - %clean present
OK - macros used consistently
OK - contains code and permissable content
OK - -doc is not needed
OK - contents of %doc does not affect the runtime
OK - no header files
OK - no static libraries
OK - no pkgconfig files
OK - no library files
OK - -devel is not needed
OK - no libtool archives
OK - %{name}.desktop file not needed
OK - does not own files or directories owned by other packages
OK - buildroot correctly prepped
OK - all file names valid UTF-8

SHOULD Items:

OK - upstream provides license text
OK - translations for description and summary
OK - package builds in mock successfully
OK - package builds on all supported architectures
OK - package functions as expected
OK - scriptlets are not needed
OK - subpackages are not needed
OK - no pkgconfig files
OK - no file dependencies

Ping?

(In reply to comment #4)

Sorry was on vacation:


> MUST Items: 
> 
> xx - rpmlint is unclean on RPM
>     + [rishi@freebook x86_64]$ rpmlint afio-2.5-1.fc9.x86_64.rpm 
>       afio.x86_64: W: spurious-executable-perm
> /usr/share/doc/afio-2.5/script2/restore

Ok, the afio includes upstream test scripts that have been put as example in the documentation. What is the best approach for this type of beast:

1/ chmod them
2/ put them elswhere 
3/ something else ?

> xx - package does not meet Packaging Guidelines
>     + Broken Source tag. Use the URL publised by upstream:
>       http://freshmeat.net/redir/afio/144/url_tgz/afio-2.5.tgz

Done.

>     + The description should be slightly more verbose than the summary.

Done.
      
>     + It might be a good idea to add a check stanza and run 'make regtest' and
>       'make regtest2gb' in it.

Is it possible to delay it after a first version of the package has been accepted ?

>     + According to
>       https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps you
>       should use 'install -p'.

I don't see exactly the point here. The Makefile provided doesn't use install.

>     + The ANNOUNCE-2.5 file contains useful information. It should be added to
>       %doc in the %files stanza.

Done. 

>     + The ChangeLog file contains no useful information. It should not be
>       distributed.

Done. 

>     + According to
>       https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation the
>       INSTALLATION file should not be distributed.

Well. Why removing information which can be useful ? You may then as well remove PORTING, the lsm file, ... 

>     + The Dist tag (ie. fc9) should not be a part of the %changelog entry. See
>       https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs

Ok, will look at that one.


> ?? - License field meets actual license
>     + The header in afio.c says:
>       "This software package can also be re-distributed under
>       particular conditions that are _weaker_ than the Perl "Artistic
>       License" combined with the GNU Library General Public License.
>       Redistribution need only satisfy all four license notices below."
>       I am not sure how this might affect the License tag. Need to verify.


> 
> OK - upstream license file included in %doc
>     + The perl.artistic.license file might need to be distributed.

Added.

> OK - spec file is legible
>     + You might want to split the %doc in multiple lines to achieve the 72/80
>       character rule. But it is a matter of style and upto you.

Done.

> xx - sources match upstream sources
>     + The MD5SUM does not match.
>       Tarball found in SRPM:
>       70fd825bd8af83473eb52d140df84cc3 
>       Upstream sources from
>       http://freshmeat.net/redir/afio/144/url_tgz/afio-2.5.tgz:
>       8c6665e0f875dcd8e1bdb18644b59688

This is due to a tool I use to help me rebuild the package. Will have a look at that as well.

> OK - package builds successfully
>     + You could consider using the attached patch to fix warnings and
>       deprecated code.
>       Getting the patch upstream should be the final goal.

Will do.


> xx - file permissions set properly
>     + The scripts in %doc should not have their executable bits set.

Linked to the upper point.

>     + The preferred attribute definition is: %defattr(-,root,root,-)

Done.

So as soon as I know what is best for the scripts in doc, I'll rebuild new packages for you to look at.
Thanks,
Bruno.

(In reply to comment #6)

> > xx - rpmlint is unclean on RPM
> >     + [rishi@freebook x86_64]$ rpmlint afio-2.5-1.fc9.x86_64.rpm 
> >       afio.x86_64: W: spurious-executable-perm
> > /usr/share/doc/afio-2.5/script2/restore
> 
> Ok, the afio includes upstream test scripts that have been put as example in
> the documentation. What is the best approach for this type of beast:
> 
> 1/ chmod them
> 2/ put them elswhere 
> 3/ something else ?
>
> [...]
>
> > xx - file permissions set properly
> >     + The scripts in %doc should not have their executable bits set.
> 
> Linked to the upper point.

Just chmod and remove the executable bits.

> >     + It might be a good idea to add a check stanza and run 'make regtest' and
> >       'make regtest2gb' in it.
> 
> Is it possible to delay it after a first version of the package has been
> accepted ?

It is possible, but it would be better to have them during the review itself, if possible. :-)

> >     + According to
> >       https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps you
> >       should use 'install -p'.
>
> I don't see exactly the point here. The Makefile provided doesn't use install.

Yes, but you are using 'install -m ...' in the %install stanza. You should use 'install -p -m ...' instead.

> >     + According to
> >       https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation the
> >       INSTALLATION file should not be distributed.
> 
> Well. Why removing information which can be useful ? You may then as well
> remove PORTING, the lsm file, ... 

The INSTALLATION file mostly talks about things that should be performed by the Fedora package -- upacking the sources, configure && make, compiler warnings that our package should try to fix, regression testing, etc.. Telling this to a user, who has got the package from a Fedora repository is redundant.

On the other hand, Fedora users _might_ be interested in knowing about how portable this program is. So it _might_ be useful to have the PORTING file.

> > xx - sources match upstream sources
> >     + The MD5SUM does not match.
> >       Tarball found in SRPM:
> >       70fd825bd8af83473eb52d140df84cc3 
> >       Upstream sources from
> >       http://freshmeat.net/redir/afio/144/url_tgz/afio-2.5.tgz:
> >       8c6665e0f875dcd8e1bdb18644b59688
> 
> This is due to a tool I use to help me rebuild the package. Will have a look at
> that as well.

Please try to fix this because the packaged source tarball should match the upstream tarball if there is no valid reason otherwise.

(In reply to comment #7)
> (In reply to comment #6)
> 
> > > xx - rpmlint is unclean on RPM
> > >     + [rishi@freebook x86_64]$ rpmlint afio-2.5-1.fc9.x86_64.rpm 
> > >       afio.x86_64: W: spurious-executable-perm
> > > /usr/share/doc/afio-2.5/script2/restore
> Just chmod and remove the executable bits.

Ok. Done.

> > >     + It might be a good idea to add a check stanza and run 'make regtest' and
> > >       'make regtest2gb' in it.
> > 
> It is possible, but it would be better to have them during the review itself,
> if possible. :-)

Indeed. I added them.


> > >     + According to
> > >       https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps you
> > >       should use 'install -p'.
> >
> > I don't see exactly the point here. The Makefile provided doesn't use install.
> 
> Yes, but you are using 'install -m ...' in the %install stanza. You should use
> 'install -p -m ...' instead.

Oops, sorry, missed that. Fixed now.

> Please try to fix this because the packaged source tarball should match the
> upstream tarball if there is no valid reason otherwise.

Yep. Agreed. I fixed the tool in the mean time.


New RPM available at ftp://ftp.mondorescue.org/test/fedora/9/afio-2.5-1.fc9.src.rpm
and spec file at ftp://ftp.mondorescue.org/test/fedora/9/afio.spec

Let me know if you think it's better now.

+ First of all, I think it would be better to skip the 2GB+ test case because our buildsystem might not always have enough disk space to run it:
    [...]
    %check
    make regtest
    # make regtest2gb
    [...]
  I should have checked it earlier before asking you to turn it on. Sorry for that.

+ The French translation of the %description stanza is still translating the older description. Would be good to fix it.

+ Ideally the URL & Source0 combination ought to be:
    URL: http://freshmeat.net/projects/afio/
    Source0: http://freshmeat.net/redir/afio/144/url_tgz/%{name}-%{version}.tgz
  You did mention a tool to generate the package, but then why is it necessary to rename the source tarball and change its URL. Without a valid reason, the URL and Source0 fields in the Spec files should point to the upstream home/project page and release tarball respectively.

The following license notice is self-contradictory. It initially implies that the program is under "LGPLv2+ or Artistic" and then goes on to impose a "non-commercial clause", which contradicts the LGPLv2.

/*
 * afio.c
 *
 * Manipulate archives and files.
 *
 * This software was written by Mark Brukhartz at Lachman Associates,
 * Inc..  Additional code was written by a large cast of people.  
 *
 * Licensing and (re)distribution
 * ------------------------------
 *
 * THE SUMMARY INFORMATION BELOW WAS WRITTEN FOR THE BENEFIT OF 
 * SOFTWARE DISTRIBUTORS
 *
 * Because of historical reasons, different parts of this software
 * package are covered by different licenses.  However:
 *
 * A) This software package as a whole may be re-distributed by any
 *    method that satisfies the conditions of both the Perl "Artistic
 *    License" and the GNU Library General Public License.
 *
 * B) According to the theory.html file of the Sunsite Archive
 *    Maintainers, this implies that the correct LSM template field
 *    is:
 *
 *          Copying-policy: LGPL
 * 
 * C) This software package can also be re-distributed under
 *    particular conditions that are _weaker_ than the Perl "Artistic
 *    License" combined with the GNU Library General Public License.
 *    Redistribution need only satisfy all four license notices below.
 *
 * Disclaimer: I am not a lawyer, and neither are the Sunsite Archive
 * Maintainers.
 *
 * END OF SUMMARY INFORMATION
 *
 * ------------------------------------------------------------------ 
 *
 * License notice 1, covering part of this software package.
 *
 * [Covers the original 1985 afio code]
 * 
 * Copyright (c) 1985 Lachman Associates, Inc..
 *
 * This software was written by Mark Brukhartz at Lachman Associates,
 * Inc.. It may be distributed within the following restrictions:
 *	(1) It may not be sold at a profit.
 *	(2) This credit and notice must remain intact.
 * This software may be distributed with other software by a commercial
 * vendor, provided that it is included at no additional charge.
 *
 *
 * [Note: it is believed that condition 5 of the Perl "Artistic
 * License" implies the intent of restriction (1) above.]
 *
 * --------
 *
 * ** License notice 2, covering part of this software package.
 *
 * [Covers the tempnam function]
 *
 * Copyright:	Copyright (c) 1989 by Monty Walls.
 *		Not derived from licensed software.
 *
 *		Permission to copy and/or distribute granted under the
 *		following conditions:
 *
 *		1). This notice must remain intact.
 *		2). The author is not responsible for the consequences of use
 *			this software, no matter how awful, even if they
 *			arise from defects in it.
 *		3). Altered version must not be represented as being the
 *			original software.
 *
 * --------
 *
 * ** License notice 3, covering part of this software package.
 *
 * [Covers the contents of the gnu.fnmatch.tar.gz file]
 *
 *  Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
 *
 *  This library is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU Library General Public License as
 *  published by the Free Software Foundation; either version 2 of the
 *  License, or (at your option) any later version.
 *  
 *  This library is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Library General Public License for more details.
 *  
 *  You should have received a copy of the GNU Library General Public
 *  License along with this library; see the file COPYING.LIB.  If
 *  not, write to the Free Software Foundation, Inc., 675 Mass Ave,
 *  Cambridge, MA 02139, USA.  
 *
 * --------
 *
 * ** License notice 4, covering part of this software package.
 *
 * [Covers the remainder of this software package]
 *
 * Additional code was written by a large cast of people.
 *
 * All additional code may be redistributed under the conditions of
 * license notice 1.
 *
 * Note that the authors of the additional code retain the right to
 * allow for the re-distribution of their code under weaker (and less
 * exotic) conditions.
 *
 * --------
 *
 * ** WARRANTY NOTICE
 *
 * THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 *
 *
 * [End of licensing and redistribution section] 
 *
 * ---------------------------------------------------------------------


Fedora Legal and the Red Hat lawyers agree that this renders this program non-free and unfit for inclusion in Fedora under the current terms.

So you and/or upstream can try to convince Mark Brukhartz <mark.brukhartz> to relicense his work and remove the "non-commercial clause". He seems to be currently working at Citadel Investment Group, Chicago. (Thanks to Tom 'Spot' Callaway for the information.)

You can also use https://www.redhat.com/mailman/listinfo/fedora-legal-list for further information from Fedora regarding this issue.

Bruno, it is better I remove myself from the review since I think you need a sponsor here. I am sorry, but I have no idea how missed this obvious fact. In the meantime try to fix the remaining problems and see if you can resolve the licensing issues. Once that is done, just give a shout in fedora-devel-list and I belive a sponsor will surely have a look at your submissions.

Good luck!

Bruno, I'm still watching this bug, if you can get the licensing issues sorted out, I'll review and sponsor.

I'll do what you have advised and will hopefully come back soon to you.

(In reply to comment #9)
> + First of all, I think it would be better to skip the 2GB+ test case because
> our buildsystem might not always have enough disk space to run it:

Ok. Done in my SVN.

> + The French translation of the %description stanza is still translating the
> older description. Would be good to fix it.

Fixed as well.

> + Ideally the URL & Source0 combination ought to be:
>     URL: http://freshmeat.net/projects/afio/
>     Source0: http://freshmeat.net/redir/afio/144/url_tgz/%{name}-%{version}.tgz

Ok.

>   You did mention a tool to generate the package, but then why is it necessary
> to rename the source tarball and change its URL. Without a valid reason, the
> URL and Source0 fields in the Spec files should point to the upstream
> home/project page and release tarball respectively.

For an external project for which I have no VCS access, you're right, it's probably useless. 

Next version will fix those. But I'll only release it when the licensing problem is solved (sent a mail today).

Hello,

I have had no feedback from a first mail sent to Mark the 30th of September.
I've resent a mail today hoping for an answer this time.

In the mean time, I have also got some feedback from lawyers that are the following:

It appears that the relevant portion of the afio license is this:

    License notice 1, covering part of this software package.
    ...
    (1) It may not be sold at a profit.
    ...
    This software may be distributed with other software by a commercial
    vendor, provided that it is included at no additional charge.
    ...
    [Note: it is believed that condition 5 of the Perl "Artistic
    License" implies the intent of restriction (1) above.]

For comparison, section 5 of Artistic License 1.0:

    5. You may charge a reasonable copying fee for any
    distribution of this Package. You may charge any fee you
    choose for support of this Package. You may not charge a
    fee for this Package itself. However, you may distribute
    this Package in aggregate with other (possibly
    commercial) programs as part of a larger (possibly
    commercial) software distribution provided that you do
    not advertise this Package as a product of your own. You
    may embed this Package's interpreter within an executable
    of yours (by linking); this shall be construed as a mere
    form of aggregation, provided that the complete Standard
    Version of the interpreter is so embedded.

There seems to be an obvious challenge: If distribution of code under the Artistic License 1.0 is OK, then what is the characteristic
of the License for afio that takes it outside of Red Hat's policy ?

Artistic 1.0 is non-free and not permissable in Fedora. However, that's not really relevant.

Keep in mind, the note is not part of the license, it is the uninformed guess of a later contributor. The original license says:

(1) It may not be sold at a profit.

The fact that there is the exception of "This software may be distributed with other software by a commercial vendor, provided that it is included at no additional charge.", and that Red Hat might meet that exception doesn't matter. It is still a use restriction, which would prevent a random individual (not a "commercial vendor") from burning Fedora DVDs and selling them on ebay

Nothing else that comes later can affect that, except for the original copyright holder of code under that license (which is why we're trying to reach him).

However, it seems Debian asked itself the same question and answered differently:

http://lists.debian.org/debian-legal/1999/05/msg00162.html and
http://lists.debian.org/debian-legal/1999/05/msg00168.html

And I have still no answer from Mark. Will try to see if I can contact him elsewhere.

The irony there is that Debian is almost certainly not considered a "commercial vendor", thus, not subject to the exception clause. Red Hat Legal has advised (and I agree) that this licensing is non-free.

So, I was about to try to reach out to Mark when I realized that he doesn't hold the Copyright on this code, Lachman Associates, Inc. does. Or rather, did.

In 1989, Lachman Associates was purchased by Eastman Kodak's Interactive Systems subsidiary (formerly ISC, acquired by Kodak in 1988). Kodak sold the Intel-UNIX operating system portion of Interactive Systems to Sun Microsystems on September 26, 1991. Kodak sold the remaining parts of ISC to SHL Systemhouse Inc in 1993.
SHL Systemhouse Inc was purchased by MCI in 1995. MCI became MCI WorldCom in 1998, which became WorldCom in 2000, went into Chapter 11 from 2002-2004, and was acquired by Verizon in 2005.

It is not clear whether the afio code was considered part of the ISC OS portion, so the copyright owner could be any of these entities (in order of probability):

1. Sun Microsystems
2. Verizon (assuming they did not liquidate the IP during Chapter 11)
3. Kodak

(sources:
http://www.lachman.org/
http://www.centergate.com/rlachman.html
http://en.wikipedia.org/wiki/INTERACTIVE_Systems_Corporation
http://findarticles.com/p/articles/mi_qa3653/is_199510/ai_n8732201
http://en.wikipedia.org/wiki/MCI_Inc.

Now, if Sun does own the copyright from the ISC purchase, they're the most likely to relicense it with a Free license. Of course, you'd need to find someone at Sun who was motivated to track this down (and whether they own it or not).

If Sun doesn't own it, then it is most likely that Verizon or Kodak owns it.
If this is the case, I suspect you have a slim to zero chance of tracking down someone at either company who is motivated to determine whether they own the afio Copyright, then who is willing and capable of relicensing that copyrighted code under a Free license.

I think you have a better chance of finding Jimmy Hoffa, but I wish you all the best. :/

Bruno: since you say that this package is not needed any more, maybe we should close this bug as CANTFIX ?

reverting for now to status "NEW" since Debarshi Ray gave up reviewing on 2008-09-26.

I'll try to contact someone I know at Sun to see if he can help me with this. Will let you know how it progresses. I'd like to wait a bit before closing it here.

(In reply to comment #21)
> I'll try to contact someone I know at Sun to see if he can help me with this.
> Will let you know how it progresses. I'd like to wait a bit before closing it
> here.

Sure. Keep in mind that we'd need some statement from Sun that they do hold the ownership of the copyright of this code.

I'm going to go ahead and mark this as not being ready for review; please clear the whiteboard if the situation improves.

I'm going to close this as CANTFIX, after consult with Simon Phipps at Sun. There is a possibility that Sun holds the copyright here, but that information is deep deep deep in storage, and Sun would have to spend a significant amount of $$$ to have that information pulled out of its off-site archives. Short of a lawsuit, this isn't going to happen.

Here is a very complete status made by the current maintainer of afio Koen Holtman <k.holtman_at_chello.nl> that deserve integration into this report for completeness. Also Cf: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509287

-----------------------------------------------------------------------
Acting as the upstream afio maintainer I just finished a LONG note on the
license status of afio.  The note includes a clarifying comment by Mark
Brukhartz, the author of the original afio license text.
I hope that this note will help the afio user community, by informing
the user community on the somewhat complex legal status of the afio
license.


Cheers,

Koen.

<start of note>

Issues with the afio license text identified in 2008 
====================================================


About afio
==========

Afio is a fault-tolerant archiver/backup tool for Unix systems.  Afio
was created in 1985 by Mark Brukhartz. Since then, many contributers
and maintainers have added features and bug fixes.  Afio is similar to
Unix tools like tar, cpio, star, and pax.  However, as a feature that
these other tools lack: afio has the ability to make compressed
archive files that are very fault tolerant against byte errors.  This
fault tolerant compression has attracted a user base that has been
sufficiently large to keep afio alive as a maintained piece of
software.

Afio project information and link to sources:
http://freshmeat.net/projects/afio/

About this note
===============

In 2008, several people have raised the question if afio can be
considered 'free' software by modern standards, see for example

https://bugzilla.redhat.com/show_bug.cgi?id=449037
http://spot.livejournal.com/303000.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509287
http://www.mail-archive.com/debian-legal@lists.debian.org/index.html#39478

A number of separate issues were raised in these discussions, this
note tries to identify and address all of them.

The answer to the question if afio is free depends partly on the
definition of free.  This note will not try to define the true meaning
of free.  The main goal of this note is to help the reader to
determine if afio is 'free software' or 'open source' or 'freely
distributable' by the definition chosen by the reader.  To meet that
goal, various valid but sometimes contradictory lines of reasoning
about 'free' will be described and discussed.

This note was written by Koen Holtman (the current afio maintainer) in
January/February 2009, based on a review of the discussions on the web
and further e-mail discussions with a number of people.

In this note, the term 'FOSS' is used to refer to the broad class of
free/open/etc software in general.  The term 'Linux distro' is used to
refer to any GNU/Linux distribution.

Disclaimer: the author of this note is not a lawyer, nor does he play
one on TV.  


Full afio license text
======================

The full afio license text (for afio 2.4.6 and later) is reproduced in
this section.

<start>
 * afio.c
 *
 * Manipulate archives and files.
 *
 * This software was written by Mark Brukhartz at Lachman Associates,
 * Inc..  Additional code was written by a large cast of people.  
 *
 * Licensing and (re)distribution
 * ------------------------------
 *
 * THE SUMMARY INFORMATION BELOW WAS WRITTEN FOR THE BENEFIT OF 
 * SOFTWARE DISTRIBUTORS
 *
 * Because of historical reasons, different parts of this software
 * package are covered by different licenses.  However:
 *
 * A) This software package as a whole may be re-distributed by any
 *    method that satisfies the conditions of both the Perl "Artistic
 *    License" and the GNU Library General Public License.
 *
 * B) According to the theory.html file of the Sunsite Archive
 *    Maintainers, this implies that the correct LSM template field
 *    is:
 *
 *          Copying-policy: LGPL
 * 
 * C) This software package can also be re-distributed under
 *    particular conditions that are _weaker_ than the Perl "Artistic
 *    License" combined with the GNU Library General Public License.
 *    Redistribution need only satisfy all four license notices below.
 *
 * Disclaimer: I am not a lawyer, and neither are the Sunsite Archive
 * Maintainers.
 *
 * END OF SUMMARY INFORMATION
 *
 * ------------------------------------------------------------------ 
 *
 * License notice 1, covering part of this software package.
 *
 * [Covers the original 1985 afio code]
 * 
 * Copyright (c) 1985 Lachman Associates, Inc..
 *
 * This software was written by Mark Brukhartz at Lachman Associates,
 * Inc.. It may be distributed within the following restrictions:
 *	(1) It may not be sold at a profit.
 *	(2) This credit and notice must remain intact.
 * This software may be distributed with other software by a commercial
 * vendor, provided that it is included at no additional charge.
 *
 *
 * [Note: it is believed that condition 5 of the Perl "Artistic
 * License" implies the intent of restriction (1) above.]
 *
 * --------
 *
 * ** License notice 2, covering part of this software package.
 *
 * [Covers the tempnam function]
 *
 * Copyright:	Copyright (c) 1989 by Monty Walls.
 *		Not derived from licensed software.
 *
 *		Permission to copy and/or distribute granted under the
 *		following conditions:
 *
 *		1). This notice must remain intact.
 *		2). The author is not responsible for the consequences of use
 *			this software, no matter how awful, even if they
 *			arise from defects in it.
 *		3). Altered version must not be represented as being the
 *			original software.
 *
 * --------
 *
 * ** License notice 3, covering part of this software package.
 *
 * [Covers the contents of the gnu.fnmatch.tar.gz file]
 *
 *  Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc.
 *
 *  This library is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU Library General Public License as
 *  published by the Free Software Foundation; either version 2 of the
 *  License, or (at your option) any later version.
 *  
 *  This library is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Library General Public License for more details.
 *  
 *  You should have received a copy of the GNU Library General Public
 *  License along with this library; see the file COPYING.LIB.  If
 *  not, write to the Free Software Foundation, Inc., 675 Mass Ave,
 *  Cambridge, MA 02139, USA.  
 *
 * --------
 *
 * ** License notice 4, covering part of this software package.
 *
 * [Covers the remainder of this software package]
 *
 * Additional code was written by a large cast of people.
 *
 * All additional code may be redistributed under the conditions of
 * license notice 1.
 *
 * Note that the authors of the additional code retain the right to
 * allow for the re-distribution of their code under weaker (and less
 * exotic) conditions.
 *
 * --------
 *
 * ** WARRANTY NOTICE
 *
 * THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 *
 *
 * [End of licensing and redistribution section] 
<end>

The remaining sections of this note address issues raised with this
license.  

The most important issue is issue number 2.  Issue number 1 is about
the question: why bother at all?


Issue 1. Why bother distributing afio if there are alternatives 
like tar and cpio with a standard OSI/FSF approved free license?
================================================================

- Issue 1 description

The afio license is not a standard OSI/FSF approved free license, in
fact it includes text written in 1985 that is widely considered to be
problematic.

There are several tools, with arguably better licenses, that are
similar to afio, e.g.

 gnu tar (GPL v3)
 gnu cpio (GPL v3)
 star (CDDL+GPL, though there seem to be some disputes about license
  compatibility)
 heirloom cpio/pax (free license)
 pax from Keith Muller

So would it not be a good thing to remove afio from a Linux distro?
Removal would make a) the license situation of the distro more
easy/pure while b) not removing any functions people need.

- Response to issue 1

1) Utility argument

The above mentioned alternatives to afio do not provide everything
that afio provides, so removing it from a Linux distro would decrease
the utility of the distro.  Some users of the distro will miss it if
it is taken out.

afio has one unique feature (fault tolerant compressed archives) that
all of the above lack.  Also, it has several specialized options that
the other tools lack, and there are deployed backup scripts that rely
on these specialized options.  Afio is also very mature (bug-free) and
portable because of its age and user base.  The user base includes
power users backing up large and complex filesystems, and these power
users have historically found and fixed very obscure bugs.  This
maturity of afio is a big advantage in a backup tool -- a
written-from-scratch replacement would take a long time to be equally
mature.

Several FOSS backup packages support afio as an archive engine, and
some were designed specifically around afio.

2) Community/historical argument

Afio is a FOSS project that started in 1985 and has grown 4-fold in
code size and features since.  Including afio into a distro shows to
potential FOSS contributers just how long such software can remain
useful, and celebrates the continuity between the current Web based
FOSS community with the historical UNIX/USENET news based FOSS
community.


Issue 2. License places limits on redistribution by some parties
================================================================

- Issue 2 description

Several definitions of 'free' software include the requirement that
any party should be able to re-distribute it.  For example.  Debian
Free Software Guideline 1 (DFSG#1) states:

  The license of a Debian component may not restrict any party from
  selling or giving away the software as a component of an aggregate
  software distribution containing programs from several different
  sources. [...]

(See: http://www.debian.org/social_contract.en.html )

The following part of the afio license can be read to contradict this:

 * This software was written by Mark Brukhartz at Lachman Associates,
 * Inc.. It may be distributed within the following restrictions:
 *	(1) It may not be sold at a profit.
 *	(2) [...]
 * This software may be distributed with other software by a commercial
 * vendor, provided that it is included at no additional charge.

The problem is that the last two lines of the above text do allow the
'selling or giving away the software as a component of an aggregate
software distribution', but they ONLY allow this, when the selling is
at a profit, if you are a 'commercial vendor'.  So for example a
private individual, who cannot be considered a commercial vendor,
would be prevented by this license from burning and re-selling a CD
including afio at a profit.  Therefore the license restricts some
parties from re-distribution, violating DFSG#1 and also DFSG#5, making
afio non-free.

- Response to issue 2

The above interpretation of the license text is a possible one, but it
is not the only possible interpretation.  If one wants to make a case
for afio satisfying DFSG#1, then one has to argue that the designation
'commercial vendor' designates very broadly ANY party that is engaged
in 'selling at a profit'.  

A private individual re-selling a CD including afio at a profit could
claim to be acting as a 'commercial vendor' as far as the meaning of
the license text is concerned.  Is such a claim credible?  I believe
it is.

Below are the two arguments why 'commercial vendor' covers any party
selling at a profit.

1) Argument by authority of the author

We managed to contact Mark Brukhartz, and after discussion of the
issues he provided a statement on the meaning of the license text that
he wrote.  The text is:

 * This software was written by Mark Brukhartz at Lachman Associates,
 * Inc.. It may be distributed within the following restrictions:
 *	(1) It may not be sold at a profit.
 *	(2) [...]
 * This software may be distributed with other software by a commercial
 * vendor, provided that it is included at no additional charge.

Here is the statement from Mark on this license text:

  It's my opinion, as the sole author of the license, that it does not
  restrict any party from selling or giving away the software as a
  component of an aggregate software distribution containing programs
  from several different sources.  Clause (1) allows the giving away
  of the software and the selling at no profit.  The text 'This
  software may be distributed with other software by a commercial
  vendor, provided that it is included at no additional charge' should
  be read as granting the additional right to sell at profit the
  software as part of an aggregate distribution -- the term
  'commercial vendor' was written to mean, and should be read to mean,
  'any seller who aims to make a profit'.

If should be pretty clear that Mark believes that the license
satisfies DFSG#1 and DFSG#5. 

I should caution the reader that this statement by Mark does not
fully resolve the interpretation issue: theoretically a judge might
disagree with Mark, and a judge is allowed to have the final
say. Also, Mark is not the legal owner of the license: Lachman
Associates owned the copyright and therefore the license, but Lachman
and its intellectual property was later sold to another company, and
it is in fact not clear which company owns the copyright to Mark's
code right now, see this link:

  http://spot.livejournal.com/303000.html

Also, after Mark wrote and licensed the original code, the afio code
base has grown by a factor of 4, so some other contributers (who
retain ownership of the copyrights to their own code) could
potentially speak up to object to Mark's opinion.  Nevertheless, as
Mark was the sole author of the license text in question, his opinion
on the interpretation of the text does carry significant weight.

2) Argument that a broad interpretation of the meaning of 'commercial
vendor' is possible and most likely

If we look up 'commercial vendor' in the dictionary
(http://www.thefreedictionary.com/), we find:

  vendor [..]
    1. One that sells or vends: a street vendor; a vendor of software
       products on the Web.
    2. [...]
  [...]

 commercial [...]
   [...]
   3. Having profit as a chief aim [...]

So it is perfectly valid to read 'commercial vendor' as broadly 'one
that sells with profit as a chief aim', meaning 'anybody who sells at
a profit'.  It is not necessary to narrowly read 'commercial vendor'
as 'a real company as opposed to a private individual'.

Also speaking for the broad interpretation is the fact that the words
'it may not be sold at a profit' were used a few lines earlier in the
license text.  It is very plausible that the term 'commercial vendor'
was used by the author as a short-hand to designate anyone doing the
opposite of 'it may not be sold at a profit'.


- Cautionary statement about the above two arguments

It should be stressed that the above arguments about the broad
interpretation of 'commercial vendor' are not 100.00% 'safe' in a
legal sense.  Any trained lawyer will immediately see that there is
some ambiguity in the afio license text, and that this ambiguity
leaves enough room for a judge to disagree with the above arguments on
why 'commercial vendor' should be interpreted broadly.  Therefore,
anybody acting as if these arguments were true runs the risk of facing
a judge who might not agree.  One of the jobs of a trained lawyer is
to identify such legal ambiguities and to deal with them -- by having
their client stop taking the risk, or by seeking out the license owner
to obtain a clarification that removes the ambiguity.  Unfortunately,
contacting the license owner is not really possible in the case of
afio, see issue #4 below.

So we are left with the following cautionary statement: even though I
believe that the arguments above are very convincing, you will be
taking a legal risk if you re-distribute afio.  I believe it is a very
small risk.  I believe that, if you are a distributer even a very
'pure' version of GNU/Linux, you are already engaged in taking
comparatively larger legal risks.  Somewhat credible parties have
stated that the Linux kernel infringes on patents that have never been
licensed for general use.  In most countries, any distributer of the
Linux kernel therefore runs the legal risk of being sued for patent
infringement.


Issue 3. License does not permit modification
=============================================

- Issue 3 description

Debian Free Software Guideline 3 (DFSG#3) states:

  The license must allow modifications and derived works, and must
  allow them to be distributed under the same terms as the license of
  the original software.

The afio license notices (except for notice 3 which is the LGPL) do
not contain any explicit statement allowing modification, or
re-distribution of modified works.  So afio fails the test of DFSG#3
and cannot be called free software.

- Response to issue 3

Under most versions of copyright law, the default situation is that
original author has the sole right of making copies, and also the sole
right of making modified copies.  So the absence of an explicit
statement in which the author also grants this right to others is
indeed cause for concern.

So we have to ask ourselves: did the copyright holders of afio in fact
grant the right to modify their work to others?  I believe they did,
so afio does satisfy DFSG#3.  I have 2 arguments why they did.

1) Argument by the contents of the license notices

If we look at the 4 license notices, we see that

- notice 1 contains the statement

   It may be distributed within the following restrictions:
   [...] (2) This credit and notice must remain intact.

- notice 2 contains the statement

   Permission to copy and/or distribute granted under the
   following conditions:
   1). This notice must remain intact. [...]

- notice 3 is the LGPL, which explicitly allows modification

- notice 4 refers to the conditions of notice 1.

So in fact notice 1, 2, and 4 all contain the clause 'this notice must
remain intact'.  Such a clause can be read to imply that 'it is not a
condition that the parts of this work outside of this notice remain
intact'.  By explicitly forbidding the modification of the notice,
they license owners are implicitly allowing the modification of other
parts of the work.  Had they wished to forbid such modifications of
the rest of the work, they would have written different license
notices.

2) Argument by implied licensing

Implied licensing is a legal principle by which a copyright owner can
be said to have granted a license for a certain type of use
implicitly, by their actions, as opposed to explicitly, by writing a
clause in a license text.  See for example:

http://en.wikipedia.org/wiki/Implied_license
http://www.iplawobserver.com/2008/09/implied-license-to-use-custom-created.html

The principle of implied licensing contradicts, to some extent, the
principle in international copyright law that all rights about which
an author remains silent are automatically assigned to the author
only, see

http://en.wikipedia.org/wiki/Copyrights#Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works

There is a growing body of (US) case law supporting implied licensing.
The most interesting part of case law for afio is the court opinion in
Field v. Google, linked from these pages:

http://www.iplawobserver.com/2006/03/googles-cache-was-fair-use-according.html
http://en.wikipedia.org/wiki/Field_v._Google#Implied_License

In this case, Field created a public web page and then objected to
this web page being available in the Google cache.  Google argued,
among other things, that they had an implied license to make the page
available via the Google cache.  The court described implied license
as follows:

  A license is a defense to a claim of copyright infringement. [...] A
  copyright owner may grant a nonexclusive license expressly or
  impliedly through conduct. [...] An implied license can be found
  where the copyright holder engages in conduct from which [the] other
  [party] may properly infer that the owner consents to his use.
  [...] Consent to use the copyrighted work need not be manifested
  verbally and may be inferred based on silence where the copyright
  holder knows of the use and encourages it.

The court found it significant that Field knew in advance that Google
would be caching his page unless he took some actions in labeling his
web site to prevent it, and that he chose not to take those actions --
Field remained silent thereby granting implied license.  If we look at
the case of afio, we can build an argument for the granting of implied
license as follows.

A. Mark Brukhartz, an employee of the license holder at the time,
   posted the afio source code, including an explicit license
   statement, to comp.sources.unix in 1987.  Link:

     http://groups.google.com/group/comp.sources.unix/browse_thread/thread/ce3312137ad92a37/ec49f37f3e59a267?lnk=gst&q=afio#ec49f37f3e59a267

B. The explicit license text was silent on limiting the right to
   modify the code.  To show that there was an implicit license of to
   modify the code, we have to show that modification was one of the
   uses that the license holder could have expected after posting the
   code to comp.sources.unix. 

C. The comp.sources community was an early FOSS community, and people
   extending other people's code was one of the things that could be
   expected in that community. Indeed the creation of such extensions
   happened almost immediately in the case of afio -- see D. and
   E. below.

D. The above newsgroup archive link shows that after Mark submitted
   the sources of afio to the newsgroup, Rich Salz, the moderator of
   the newsgroup, added a Makefile to the sources before forwarding
   them to the group, thereby in fact distributing a modified version
   of afio.  It was common practice for Rich Salz to add a Makefile
   when submitted sources did not have them; the license holder would
   probably have known this -- and took no steps to forbid it.

E. Mark did not explicitly object when modifications to afio were
   posted.  For example, three days after the afio post to
   comp.sources.unix, Karl Denniger posted an improvement for afio to
   comp.sources.d (an unmoderated companion newsgroup to
   comp.sources.unix), with the description:

      These are context diffs to the 'afio' program, a cpio
      replacement, that was posted recently.  The changes here take
      care of what I saw as a possible 1gaffe in the '-y' and '-Y'
      options.

   Link: http://groups.google.com/group/comp.sources.d/browse_thread/thread/381df257b583954e

F. The license holder knew that it was common practice to modify code
   posted to comp.sources.unix. To illustrate that Lachman Associates
   would have been well aware of the practice of extending software
   tools in the context of the comp.sources newsgroups: in 1989, two
   Lachman employees greatly extended a terminal emulator program
   written by someone else in 1986, and posted their extended version
   to comp.sources.atari.st, see:

    http://groups.google.com/group/comp.sources.atari.st/msg/95d006760c056af1


Given all of the above, it can be argued that the actions of Mark
(while he identified himself as working for the license owner Lachman
Associates) constituted the granting of an implied license to modify
afio.  

The current version of afio contains many contributions by other
people than Mark, and these contributors typically did not add any
license texts of their own. For these contributions, similar arguments
for the granting of implied license to modify can be made.

Note that the principle of implied licensing has been developed mostly
through recent US case law; as far as I know it is still absent from
international treaties.  So in some locations, invoking this principle
will be legally more risky than in other locations.  A trained legal
person would prefer to avoid a reliance on implied licensing whenever
possible.


Issue 4. Afio should be re-licensed under a better license
==========================================================

- Issue 4 description

Various software packages which had problematic licenses have now been
re-licensed under better licenses.  Often they have been re-licensed
under OSI/FSF approved licenses.  The same should be done with afio.

- Response to issue 4

It would be nice if re-licensing of afio were possible, but it is not
possible in practice.

Afio, in the current 2.5 version, is not the in-house product of a
single company.  In the 22 years since Mark Brukhartz posted afio to
comp.sources.unix, the FOSS community has added many features which
have made the package grow by a factor of 4.  Several authors have
contributed major pieces of code to afio, and many more contributers
(an estimated 40-100 people) provided patches, ideas, and example
scripts.  The afio sources do not contain complete log files
containing the names of all contributers, so contacting all of them,
which would be required by copyright law in order to re-license afio,
is a virtually impossible task.  Furthermore, as mentioned above, Mark
Brukhartz is not the owner of the copyright of the original afio code,
Lachman Associates owned this copyright, and it is unclear which
company owns it now (see http://spot.livejournal.com/303000.html).
That company would have to be identified and would have to be willing
to re-license.

As an alternative to re-licensing ALL afio code, it would be possible
to try to find a subset of the contributers and ask them to re-license
their own contributed code.  Depending on the success in finding the
contributers, this could (according an the estimate of the current
maintainer) bring about 30-60% of the afio code base under a new
license. However, but such an action would not satisfy those seeking
legal clarity on the status of afio as a whole.

Some software projects have managed to improve their license situation
by re-writing from scratch those parts of the code that had
questionable or unknown licenses.  However, for afio this would mean
rewriting 30-70% of the code.  Any such re-write would introduce a lot
of new bugs, which is not desirable in a mature backup tool.


Issue 5. What about the Copying-policy: LGPL thing in the license text?
=======================================================================

- Issue 5 description

The license text includes at the start a summary

 * THE SUMMARY INFORMATION BELOW WAS WRITTEN FOR THE BENEFIT OF 
 * SOFTWARE DISTRIBUTORS

and this summary text  explains how

 *          Copying-policy: LGPL

is the right LSM template value for afio.  

The writing of this summary information has been interpreted by some
sources as an attempt to re-license afio under the LGPL, see
e.g. http://spot.livejournal.com/303000.html.

So one might ask: is this summary information an attempt a
re-licensing, and if not, why is it there?  

- Response to issue 5

(Response written by Koen Holtman, author of the SUMMARY INFORMATION
in question, partly based on personal recollections)

The summary information is definitely not an attempt at relicensing. A
close reading should make this clear. 

The summary information was added to afio in November 1999, it was
prompted by the fact that the sunsite/ibiblio/metalab FTP site robots
at that time stopped accepting random strings Copying-policy field of
the .lsm file.  (.lsm is a metadata file format for describing FOSS
software packages on FTP sites) The FTP site robots only accepted
certain fixed strings like 'LGPL'.  See the following web page:

http://web.archive.org/web/20001117112300/http://www.ibiblio.org/pub/Linux/LICENSES/theory.html

The LGPL label was chosen by Koen Holtman among the possible fixed
strings based on the contents of the web page above.  Note that the
Perl Artistic license referred to at the time was the 'original' Perl
artistic license of 1997 which contains the following text:

   You may charge a reasonable copying fee for any distribution of
   this Package. You may charge any fee you choose for support of this
   Package. You may not charge a fee for this Package itself.

Several people have since argued that part of the Artistic license
text has problems, and a new version of the Artistic license (v2.0)
was written that excludes this text.

In an interesting twist, the site freshmeat.net at one point seems to
have imported the computer-readable .lsm file of afio, using the
Copying-policy line to create a 'license' line on the web site:

 [License] OSI Approved :: GNU Lesser General Public License (LGPL)

(see http://web.archive.org/web/20070930211041/http://freshmeat.net/projects/afio/ )

So the interaction between the sunsite and freshmeat automatic robots
seems to have effectively 'laundered' the complex license status of
afio.  Then, the FSF seems to have copied the data from Freshmeat:

http://web.archive.org/web/20080109010049/http://directory.fsf.org/project/afio/
Both these directories have since been corrected.


Issue 6.  Several people working for/with FOSS related
organizations have called afio not-free.
=======================================================

- Issue 6 description

In his blog post at http://spot.livejournal.com/303000.html , Tom
Callaway, who works on Fedora legal issues, quoted the 1985 part of
the afio license and wrote:

   Now, this license isn't free.

Tom then goes on point out that the main problem with the license is
with the 'It may not be sold at a profit.' clause, i.e. issue 2 above.

At https://bugzilla.redhat.com/show_bug.cgi?id=449037, similar
conclusions are drawn, and the issue of including afio in Fedora is
closed as 'cannot fix'.

In response to issues raised by Tom Callaway, the FSF reviewed the
afio license and removed afio from it's Free Software directory.  (See
a note by Brett Smith in the comment track at
http://spot.livejournal.com/303000.html.)  This removal means that the
FSF determined that the afio license is non-free by FSF standards.

So it seems like expert opinion is going against the idea that afio
is free.

- Response to issue 6

Are the experts above wrong?  I believe that they have made no logical
errors in their reasoning -- it looks like they correctly applied a
set of rules to determine freeness.  So if we are to make a case for
afio being 'free' by some definitions, we are down to examining the
rules that were applied, and showing that at least one of them is not
included in all possible definitions of 'free'.

In the discussions in the links above, we find that the people
involved, in so far as they explain their reasoning, are referring to
the same definitions of 'free' I have used in this note, e.g.  Debian
Free Software Guideline #1.  However, the conclusions about freeness
drawn are generally more negative than my conclusions in this note.
Why?

I believe that the people in the links above are all using the
following rule when applying guidelines for freeness:

 worst-case-rule: If the license text is ambiguous, in a way that would
 leave enough room for a judge to disagree that the license meets our
 written definition of 'free', then the license should be treated as
 non-free.

In my own analysis of the legal issues above, I have avoided applying
this worst-case-rule by default.  I have however tried to identify all
possible places where this worst-case-rule could be applied.

It is very common for trained lawyers to apply this worst-case-rule,
to go by the worst possible interpretation of an ambiguous legal text.
In fact, in a multidisciplinary business team, one of the key skills
that a lawyer is expected to bring to the table is the skill to find
the legal ambiguities and worst-cases.

In the FOSS context, the worst-case-rule has often been used when a
large company (e.g. Netscape, Sun, Microsoft) created a specialized
license to go with a specific piece of software that the company
wanted to share with or contribute to the FOSS community.  Arguably,
it is a good strategy in such a case for the FOSS community to assume
the worst possible interpretation of the license text concerned.  The
use of the worst-case-rule has sometimes led to companies improving
their license texts from a FOSS community point of view.

However, I would argue that applying this worst-case-rule to afio, a
historical product of the FOSS community for which the license text
cannot be changed anymore, is like throwing out the baby with the
bathwater.  There is no need to treat afio as if it might be a
carefully constructed Trojan horse.

So I feel that applying the worst-case-rule is fine in come cases, but
destructive in others.  Does this mean that I am arguing for a double
standard as far as the legal analysis of FOSS licenses is concerned?
I am not -- in the end, a legal analysis is a determination of the
risk of getting sued and of losing in court when one is sued.  This
risk cannot be determined correctly by doing a narrow analysis of the
license text under the worst-case assumption that the other party is
out to get you.  Other factors, like those considered for afio in this
note, should also play a role in legal risk determination.

I believe that a strict application of the worst-case-rule, when
judging a software package against e.g. the Debian Free Software
Guidelines or the four kinds of software freedoms defined by the FSF,
will lead to results that are counter-productive for the FOSS
community:

  - The worst-case-rule will lead to a favoring of software packages
    released in one go by a single company over almost all software
    packages that were grown over many years by volunteer contributors
    using the Internet.  Most volunteer software will look worse
    through the lens of the worst-case-rule, because of the way
    copyright law works.  In a worst-case legal analysis, copyright
    law requires that all volunteer contributers have made explicit
    statements placing their contributions under a free license.  If
    one such statement is missing, then there exists an ambiguity in
    that author's wishers, that has to be interpreted by the
    worst-case-rule as a lack of permission to copy or modify.

  - Living with the worst-case-rule in a FOSS project will raise
    barriers of entry for contributers to FOSS projects, because these
    contributers would have to be asked to make legal statements
    licensing their contributions, instead of relying on the principle
    of implicit license.

  - The worst-case-rule will favor software projects that were started
    recently over some longer-running software projects, because only
    the recent projects could start with license texts that have been
    constructed to be unambiguous according to the most recent legal
    insights.

In conclusion, I believe that the reason why the experts in the links
above found afio to be non-free is that they all implicitly or
explicitly applied the worst-case-rule.

I do not want to argue that the worst-case-rule should never be
applied.  In fact, a Linux distro based on the strict application of
the worst-case-rule could be considered valuable by some, and some
distributions that are looking to be '100% free' seem to be applying
this rule.  Note that '100% free' according to the worst-case-rule
does not mean '100% elimination of all legal risks to the user'.  No
Linux distro can be 100% pure in this way: the kernel alone comes with
patent risks.

I believe that the worst-case-rule should not be used by more general
Linux distros, unless it is combined with a moderating principle.
Without a moderating principle, the worst-case-rule has negative
effects on the community aspects of FOSS.

Conclusion
==========

This note has addressed several questions that have been raised on the
status of afio as 'free' software.

The best argument for afio being 'non-free' is that the afio license
text that was written in 1985 fails the test of the worst-case-rule:
the text is ambiguous in a way that would leave enough room for a
judge to disagree that the license meets e.g. Debian Free Software
Guideline 1.

The best argument for afio being 'free' is that the worst-case rule
should not be applied in the case of afio, because it is the product
of a long-running FOSS effort, and because the ambiguities in the 1985
license text, when examined in context, do not create any practical
barriers against exercising the freedoms that a modern FOSS user or
distributer expects to have.  I believe that legally speaking, if a
user, programmer, or distributer treats afio as 'free' software, the
risk of having a court conclude that they are in violation of the afio
license is very low, low enough to be lost in the background noise.

It is not always morally right to treat copyrighted works in a 'free'
way, just because the legal risks of doing so are low.  But in the
case of afio I believe treating it as 'free' it is definitely morally
right, because this what the authors intended.


<end of note>
-----------------------------------------------------------------------

I chose to post this note as I feel in agreement with Koen's perception, his will to help old but still useful software to stay around as a gift, and my personal will to consider it as free for the MondoRescue project that is currently using it.

It is worth noting that I strongly disagree with Koen's perception. It is incredibly unlikely that we will ever include afio due to its licensing issues.

We have zero visibility on the intentions of the initial copyright holder, nor do we know who that is anymore. Koen's assumptions seriously stretch the bounds of existant copyright case law.

Leaving this as CLOSED, CANTFIX.

(In reply to Tom "spot" Callaway from comment #26)
> It is worth noting that I strongly disagree with Koen's perception. It is
> incredibly unlikely that we will ever include afio due to its licensing
> issues.
> 
> We have zero visibility on the intentions of the initial copyright holder,
> nor do we know who that is anymore. Koen's assumptions seriously stretch the
> bounds of existant copyright case law.
> 
> Leaving this as CLOSED, CANTFIX.

Tom, I still want to use it, is it OK to put it to RPMFusion non-free?

That's up to RPMFusion, but I would not recommend it.