[OpenAFS-devel] OpenAFS Licensing Update Discussion
Tue, 15 Jun 2021 18:29:56 -0700
Thanks for writing up your notes.
As requested, reconciling with my notes inline...
On Tue, Jun 15, 2021 at 09:04:41PM -0400, Jeffrey E Altman wrote:
> Following today's AFS Technology Workshop session many participants met
> via Zoom to discuss the proposal to dual-license portions of the OpenAFS
> source tree required to build the Linux kernel module under both the IBM
> Public License 1.0 and GPLv2. The following preliminary conclusions
> were reached:
> * Follow up discussions on re-licensing will occur on the
> firstname.lastname@example.org mailing list. The Reply-To on this e-mail
> has been set accordingly. Please join the email@example.com
> mailing list to participate in the discussions.
I don't specifically remember that being mentioned, but it seems
appropriate, since the key actions will be gaining permission from
developers to effectuate the relicensing.
> * The target will be re-licensing of the minimal source code set
> necessary to produce a GPLv2 kernel module. There are members of
> the community (myself included) that will object to re-licensing BSD
> or MIT licensed contributions as GPLv2 unless doing so is required.
> * Cheyenne Willis pointed the group at the LWN article "Relicensing:
> what's legal and what's right"
> * Simon Wilkinson referenced
> * We discussed the re-licensing of the Sun RPC code which was included
> by IBM in OpenAFS 1.0 but is not covered by the IBM Public License 1.0.
> Based upon the discussions I have pushed to openafs gerrit a change
> to apply the new Oracle 3-clause BSD license to OpenAFS on the
> condition that IBM and all contributors that modified the affected
> files agree.
> * Subsequent to IBM publishing the revised IBM DeveloperWorks OpenAFS
> 1.0 dual-licensed version, I have agreed to seek the assistance of
> the Software Freedom Law Center in drafting appropriate Contributor
> License Agreements (CLAs) for individuals and organizations to
> execute. The CLAs will be scoped to the set of files necessary to
> build a "Dual IPL20 and GPLv2" kernel module.
My notes indicate that Todd had also indicated willingness to do this part.
Also that this is one of the highest priority action items (along with
getting a public/archived copy of the dual-license declaration from IBM),
since we can't start getting developer assent or making changs to the
approval workflow for changes to master until the CLA text is known.
> * It is proposed that the CLAs be maintained by the OpenAFS Foundation
> or the Software Freedom Law Center.
> In order to narrow the scope of work the contributors that are known to
> have contributed tens or hundreds of commits to the necessary source
> files will be approached to execute CLAs first.
> The re-licensing of the the Sun RPC sources will be performed in
> parallel with the relicensing of the Linux kernel sources. As soon as
> the necessary CLAs are obtained for the Sun RPC sources, the relicensing
> of those files to 3-clause BSD can be merged.
> Gerrit will be modified to contain an additional column to record
> acceptance of GPLv2 and IPL10 dual licensing for new submissions. A
This might be a little more specific than what is needed (and what's in my
notes). My understanding is that specific assent to exactly the
GPLv2+IPL10 combination is not needed, and that a BSD/GPLv2 license might
fulfil the legal requirements of our scenario. I trust that the SFLC will
be able to provide guidance on this topic. (The bit about having a column
in gerrit to track the licensing approval for commits that touch the
relevant files does match up with my notes, though.)
> list of source files that must remain dual licensed will be maintained
> in the source tree. The addition and removal of source files from the
> Linux kernel build will require modification of this list.
This list of files will be important for determing which commits are
affected by the CLA/licensing-permission requirement. So, it would be an
input to determining which historic commits need to get retroactive
approval for relicensing, and looking forward it will determine which new
commits need to have the column in gerrit set before they can be merged.
When I was writing my notes it seemed like there would be a more
qualitative difference in the past-changes vs future-changes handling
(e.g., commit vs file granularity), but going over them now I am not sure
there is so much of a difference -- it's going to be "all commits that
touch any of these files" in both cases.
> Although the initial work will be performed on the "master" branch, it
> is the hope of many that dual licensing can be back-ported to the
> existing stable releases.
> To the other participants, if I made any mistakes or omissions in this
> summary, please follow up with corrections.
We also talked a bit about "works for hire" and the need for corporate CLAs
(CCLAs) to cover those cases.
> Thank you for all that have expressed interest in a GPL licensed OpenAFS
> kernel module.
> Jeffrey Altman
> On 6/10/2021 7:23 PM, Todd DeSantis (firstname.lastname@example.org) wrote:
> > Greetings OpenAFS Community
> > I would like to introduce an OpenAFS community proposal to change the
> > licensing terms for future releases of the kernel components of
> > OpenAFS. Today OpenAFS is exclusively available under the IBM Public
> > License (IPL-1.0). Due to OpenAFS having some Linux kernel modules,
> > the IPL is not optimal for development and consumption of the kernel
> > code on Linux. We're proposing that, going forward, OpenAFS kernel
> > components should be available under a dual licensing model - the GNU
> > GPL Version 2 and the existing IPL-1.0. Based on a recent request from
> > the community, IBM is already in support of and working toward the
> > dual licensing change for the OpenAFS kernel components.
> > This change has many benefits for the OpenAFS community as well as
> > users of OpenAFS in Linux environments. Having the OpenAFS kernel code
> > available under the GNU GPLv2 will provide the appropriate licensing
> > model for the OpenAFS Linux kernel code that meets current Linux
> > kernel licensing standards. The time has come to institute this change
> > and your agreement and support is needed.
> > *Among the many benefits of OpenAFS kernel components under the GPLv2
> > include: *
> > * Avoidance of tainting Linux kernels when OpenAFS kernel components
> > are installed
> > * Ability to leverage modern Linux kernel features
> > * Opportunity to distribute OpenAFS kernel modules in Linux
> > distributions
> > * Hosting of OpenAFS kernel support on POWER architecture
> > *In order to realize the advantages of the dual-licensing model for
> > the OpenAFS kernel components, the following items need to be addressed: *
> > * Identify what OpenAFS source code needs to be licensed under the
> > dual licensing model - the GNU GPL Version 2 and the existing IPL-1.0.
> > * Obtain agreement from all OpenAFS code Copyright holders to
> > dual-license their code contributions under the GPLv2 and IPL-1.0.
> > This will be accomplished with a new OpenAFS Contributors License
> > Agreement (CLA) and Corporate Contributors License Agreement
> > (CCLA) to be drafted and used for this effort.
> > * Clean-room code module replacements in situations where Copyright
> > holders cannot be found or will not agree to the licensing change
> > * Annotate each OpenAFS source file with the appropriate GPLv2 and
> > IPL-1.0 notices.
> > * Add MODULE_LICENSE("GPL and additional rights"); to the OpenAFS
> > kernel source files and other technical code updates.
> > We will have a discussion on the Dual Licensing effort during the AFS
> > Technologies Workshop -- June 14th through June 16th via a Virtual
> > Workshop during the "IBM Status Update" session on Tuesday, June 15th
> > in the 10:15 to 10:45 slot.We may also have a BOF session on this
> > subject later on Tuesday or Wednesday during the Workshop.
> > Here's a link to the AFS Technologies Workshop page:
> > _https://workshop.openafs.org/afsbpw21/_
> > <https://workshop.openafs.org/afsbpw21/>
> > The OpenSSL Community went through a similar license activity a few
> > years back and here is a pointer to that site.
> > _
> > __https://www.openssl.org/blog/blog/categories/license/_
> > <https://www.openssl.org/blog/blog/categories/license/>
> > A link to the CLA details that the OpenSSL effort used is
> > https://www.openssl.org/policies/cla.html
> > <https://www.openssl.org/policies/cla.html>
> > The OpenAFS Community might do something like this as well to help
> > group contributors with contributions and what area of the code it
> > hits, etc.
> > Please use the email@example.com_
> > <mailto:firstname.lastname@example.org>mailing list as the list to be used
> > for discussions regarding re-licensing.
> > Thanks for your help and support on this important initiative.
> > Todd DeSantis
> > IBM AFS Support
> > OpenAFS Foundation Board Member