[CentOS-devel] OT: OpenAFS history was Re: RFC: kmods SIG Proposal

Wed May 26 20:56:54 UTC 2021
Jeffrey E Altman <jaltman at auristor.com>

This e-mail is very much off-topic for this list.   However, the "kmods 
SIG Proposal" thread included a number of statements or assertions that 
I felt should be clarified.

On 5/23/2021 8:31 AM, ngompa13 at gmail.com (Neal Gompa) wrote:
> On Sun, May 23, 2021 at 8:08 AM redbaronbrowser
> <redbaronbrowser at protonmail.com> wrote:
>>
>> On Sunday, May 23, 2021 6:14 AM, Neal Gompa <ngompa13 at gmail.com> wrote:
>>
>>> On Sun, May 23, 2021 at 6:44 AM redbaronbrowser
>>> redbaronbrowser at protonmail.com wrote:
>>>
>>>> This seems like a next level example of irony when the IBM/RH Legal department says that a IBM/RH sponsor project can't package/distribute a IBM/RH FOSS project because of the license that IBM/RH choose.
>>>> At some point it would be nice if OpenAFS project which is made up mostly of code owned by IBM/RH could acknowledge the issues that IBM/RH Legal department raises and address them so that CentOS, a IBM/RH sponsor project, can distirbute the kernel module someday in the future.

The IBM OpenAFS 1.0 release was posted to the IBM DeveloperWorks web 
site on 31 October 2000.  This release was a fork of the commercial IBM 
AFS 3.6 product which continued to be developed and supported for more 
than a decade after the publishing of OpenAFS 1.0.  IBM OpenAFS 1.0 was 
the first and only release from IBM.  It consisted of a tarball and a 
LICENSE file containing the text of the IBM Public License 1.0 license.

The OpenAFS Project (www.openafs.org) was formed in the days that 
followed as an unincorporated association with participation from CMU, 
MIT, UMich, IBM, Intel and Morgan Stanley.  The initial commit to the 
CVS repository (since converted to Git) was

     commit 87c10e8d7f05dbbdf12ee9e8651dcec07e08af3f
      (tag: openafs-root, tag: openafs-ibm-1_0)
     Author: IBM <IBM>
     Date:   Sat Nov 4 02:13:13 2000 +0000
        Initial IBM OpenAFS 1.0 tree

     3456 files changed, 968066 insertions(+)

The IBM Copyright and License information were added to each source file in

     commit fb5bcd00fc6f1560d7d02115a0b5beaa3014a0e7
     Author: Daria Phoebe Brashear <shadow at dementia.org>
     Date:   Sat Nov 4 10:01:08 2000 +0000
       Standardize License information

    2058 files changed, 15605 insertions(+), 5719 deletions(-)

The tip of the current development branch is 
72223e0958c2d7cddd968970547dd73fc3cc135.

git diff -w --stat fb5bcd00fc6f1560d..72223e0958c2d reports

     5447 files changed, 1062235 insertions(+), 319453 deletions(-)

Commits are attributed to 254 unique email addresses; some of which 
belong to the same entity.  Attributing these identities to lines of 
code via git blame results in the following top ten contributors across 
the entire repository.

     36%	495583	IBM
     19%	263820	Jeffrey Altman
     9%	116742	Daria Phoebe Brashear
     4%	54518	Chas Williams
     3%	42678	Peter Scott
     3%	40844	Simon Wilkinson
     3%	39423	Russ Allbery
     2%	32698	Andrew Deason
     2%	32420	Asanka Herath
     2%	29272	Dave Tanner

IBM is still the largest contributor but it has not been a majority for 
many years.  IBM is attributed at a lower percentage when only the files 
required for the Linux kernel module are examined.

By the time I joined The OpenAFS Project (2003) the challenges of 
OpenAFS being both out-of-tree and GPL-incompatible were well understood 
by the community.  Conversations with IBM regarding re-licensing of IBM 
OpenAFS 1.0 began in 2005 and continue to this day.

>>> You seem to be under the impression that IBM actually is doing
>>> anything with Red Hat on this. They're not. Red Hat and IBM have
>>> separate legal departments entirely. Also, since OpenAFS has had
>>> contributions from folks other than IBM, it's not straightforward to
>>> relicense the project anymore.

A re-license by IBM of the original IBM DeveloperWorks release is a 
necessary step in any effort to re-license OpenAFS.  There are more than 
13500 commits from non-IBM entities; approximately 3700 impact the Linux 
kernel module.  Not all of those commits are visible in the current 
development tip.  Re-licensing is not out of the question but it is 
important to recognize the limits of what re-licensing can achieve.

After all contributors grant permission, the Linux kernel developers 
must be convinced to accept a dual-GPL/IPL10 license as a GPL compatible 
license.  Assuming the change is accepted, the OpenAFS kernel module can 
make of GPL_ONLY functionality.  That is a huge win. However, it will 
not result in OpenAFS being accepted into the Linux kernel.  There are 
and will continue to be objections to its monolithic architecture 
combining filesystem, networking, and crypto all in one module.  In 
addition to objections over pioctls, pags, its cross-platform code base, 
etc.

In addition, there is already an actively maintained implementation of 
AFS functionality in the Linux mainline kernel.  The clean room 
development of the in-tree AFS and AF_RXRPC implementation began in 2001 
and was actively supported by The OpenAFS Project up until my departure 
in 2012.  This functionality has been shipped as part of Fedora since 
31, is included in Ubuntu 20.10, and will be included in Debian 11 
"bullseye".

>> I don't expect a transistion to happen over night.  If RH Legal continues to indicate there is good reasons why OpenAFS kernel modules can not be distributed in a CentOS SIG at the beginning of 2022, I can be understanding about that.
>>
>> But there should be a path way forward for OpenAFS inclusion in the SIG someday if IBM and Red Hat are to be taken at their word.  And it should be our obligation as a community to clearly state what our needs from those open ended offers are.

While I continue to support efforts to encourage IBM and the OpenAFS 
developer community to re-license OpenAFS, I continue to believe that 
most efforts should be focused on improving the in-tree AFS and AF_RXRPC 
implementations rather than OpenAFS.  Only the in-tree implementation 
can provide universal out-of-the-box /afs global namespace access. 
Out-of-the-box /afs is necessary for supporting a variety of container 
deployment workflows that require a ubiquitous secure global namespace 
across multi-clouds.

AF_RXRPC independent of AFS also has the potential to be a lightweight 
secure alternative for IoT services.

> Second, IBM hasn't owned the OpenAFS project for many years. It was
> spun off in 2013 to the OpenAFS Foundation[1]. 

The OpenAFS Project has been independent of IBM from its inception.  The 
OpenAFS Foundation was founded in 2013 to provide a not-for-profit 
corporate entity to manage money and sign contr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jaltman.vcf
Type: text/x-vcard
Size: 271 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210526/46c564d0/attachment-0005.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210526/46c564d0/attachment-0005.sig>