[AFS3-std] IBM will not re-license OpenAFS .xg files

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBA6C2408E3AA81E8A1987DE3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, August 27, 2012 9:37:10 PM, Russ Allbery wrote:
> "Chas Williams (CONTRACTOR)" <chas@cmf.nrl.navy.mil> writes:
>> Russ Allbery writes:
>
>>> This basically makes it impossible to publish, as an RFC, a
>>> specification for the existing protocol or any new work that is, from=
 a
>>> legal perspective, a derived work of the existing *.xg files as
>>> released by IBM, until such time as someone reverse-engineered the
>>> protocol specification in a clean-room environment, or unless the RFC=

>>> Editor would be willing to publish documents covered by the IBM Publi=
c
>>> License.
>
>> what is the origin of the arla .xg files?  they seem to have the
>> 3-clause bsd license but if they were written using the ibm
>> documentation they are potentially tainted.
>
> Ah, yes, that's a good point.  Those may be clean-room reimplementation=
s,
> in which case they could be used as a starting point.

I have been pursuing the relicensing with IBM ever since the afs3-stds
process was proposed because

1. The Arla files are unlikely to be clean enough.  They were not
   developed in a clean environment.

2. The Arla files are 3-part BSD and would need to be re-licensed
   themselves to be compatible with the RFC Editor requirements.

3. The Arla xg files are incomplete.

>>> (Note that a cogent legal argument can be made that there are no such=

>>> derived works or barriers to publication on the grounds that the
>>> existing files are not copyrightable, but the RFC Editor lawyers woul=
d
>>> have to be satisfied with such an argument despite what amounts to a
>>> contrary opinion from IBM.  This strikes me as unlikely.  It's the ki=
nd
>>> of legal risk that the RFC Editor is highly unlikely to take for
>>> something that's not IETF work and is going through the independent
>>> submission track.)
>
>> ibm said they didnt want to relicense the files.  that doesnt mean tha=
t
>> the current license is meaningful when it comes to the .xg files since=

>> they are essentially prototypes.
>
> My opinion of what we've heard from IBM, which is admittedly based on
> second-hand information and is purely my personal opinion, is that IBM
> believes the files are covered under the IBM Public License and are
> copyrightable.  Whether they would bother to try to defend that positio=
n,
> or would even continue to hold that position if it were seriously
> challenged, is another question on which I would not speculate.  I thin=
k
> they hold the position by default, rather than as a considered legal
> opinion.  But that's my impression of their position.
>
> I have no intention of pursuing any of this further and don't plan to h=
ave
> any further involvement in the problem, so other people should absolute=
ly
> feel free to discount or disregard that opinion and proceed via whateve=
r
> course of action they feel is appropriate.  It will be very difficult t=
o
> get IBM to express any sort of opinion on the record or in public, if p=
ast
> experience is any guide.  (Which makes sense from a lawyer's perspectiv=
e;
> silence does them no harm.)

Unlike Russ, I have had direct discussions with various IBM attorneys
over the last five years.  There is more than reasonable evidence to
support the position that when IBM released the IBM DeveloperWorks
OpenAFS source package and wrapped it with the IBM Public License 1.0
that the license was intended to apply to all source files within the
source package that were not copyright by another party.  As part of the
process of creating the first OpenAFS.org release the license was
applied in that fashion to each and every source file in the tree which
makes it hard to argue that the community founders didn't agree with
that interpretation.

Altering the license text on the .xg files was not the only change that
was requested of IBM.  The OpenAFS Elders also pursued altering the
licensing on rx which could have been released as public domain based
upon the DARPA funding that originally created it.  We also pursued
changing the license on the documentation.

I believe that interfaces should not be copyrightable.  However, there
is no law to that effect and recent court decisions in the Oracle vs
Google case over the use of a Java-like programming language and
associated class libraries left a very murky picture of how courts would
rule.  I am not a lawyer but my interpretation of the decision was that
the Java interfaces are copyrighted but that Google did not violate the
copyright and hence there were no damages.
This decision is of course being appealed.

In any case, over the last seven years I have held out hope that if only
the right person within IBM could be found that the licensing could be
changed and that IBM would relinquish the "AFS" and "OpenAFS"
trademarks.  I am now convinced that the discussions have reached an end
and that there are no stones left unturned.

Jason asked what the impact of this decision has on the AFS3
standardization process.  This decision means that the IETF and the RFC
Editor cannot be used to publish archival copies of protocol documents
that are created by this group.  This group can still publish documents
on a web site of its own, via mailing list archives, or many other
methods.

Jeffrey Altman


--------------enigBA6C2408E3AA81E8A1987DE3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQPTlaAAoJENxm1CNJffh4pE8IAKah/9iV4JZzcpiAu3KX8b75
Qnif/PiBoDxMJ9cI5uMHsdbsmgIcopcn1QReGWNMCYac6Oh5MJz6pmX3O2MEbAyH
0/HqBNDEZAyzgD0+PZip8IM6/6giscul2NRnWSpN8OnoGu1KWtC/iPoJZOqAu0rW
0xzHDN4bneyHPcMNAwagy+zoKhuw8K2aNO0rocOAyr/hZhi0jw4pHFr8QRYMvYrN
PKn0/bWp9xttb7IF1lHmSB9Vq7vQT9YjPOMwOczkghyFOmrAuxMLD+blFcs1QgGU
xDssYpDj/l+EXXmMbZJYJi3Q7VRl4xP1cN8ocIsRJhbwkq80e5SKHa/jeAw/DN4=
=kJlP
-----END PGP SIGNATURE-----

--------------enigBA6C2408E3AA81E8A1987DE3--