[OpenAFS-devel] openafs / opendfs collaboration

Jeffrey Hutzelman jhutz@cmu.edu
Thu, 20 Jan 2005 20:24:23 -0500


On Tuesday, January 18, 2005 16:46:14 -0500 Tom Keiser <tkeiser@psu.edu> 
wrote:

> Given that OpenAFS and OpenDCE have been released under different licenses
> (IPL versus LGPL), is there any chance of code sharing, or other forms of
> collaboration?  If there is possibility for code sharing, is it
> bidirectional or unidirectional?

Disclaimer: I am not a lawyer, and the following is not legal advice.


In general, it's going to be tricky, because of certain terms in the IBM 
Public License which render it not GPL-compatible.  Particularly, the IPL 
requires people who contribute code which implements a patent they hold to 
also grant certain rights to use that patent to anyone to whom the combined 
program is distributed (there are limitations on these rights; read the 
license for details).  The GPL does not contain this requirement, and does 
not permit people distributing GPL'd code to add such a requirement.

Under the normal GPL, if you combine GPL'd code with other code, the 
resulting combination can be distributed only under the terms of the GPL. 
So incorporating a piece of IPL'd code into GPL'd software would result in 
something you could not distribute, because both the IPL's patent rights 
provisions and the GPL's prohibition of such changes would apply at the 
same time.  Similarly, you can't incorporate a piece of GPL'd code into 
OpenAFS, for essentially the same reason.


The fact that OpenDCE was released under the LGPL makes the issue more 
interesting, but not really easier.  For one thing, the LGPL was really 
intended to be used only for libraries, and some of its terms reflect that. 
For example, it allows a derivative work to be prepared and distributed 
under its terms, but says "The modified work must itself be a software 
library."

The LGPL makes a distinction between works which contain parts of the 
library or are modified versions of it, and things that merely use the 
library, and apply different terms to them.  Specifically, a program that 
uses an LGPL'd library does not have to be distributed under the same terms 
as the library.  As a result, it is possible for an LGPL'd library to be 
used by software covered by another license, including the IPL.



So, if OpenDCE includes a library that performs some interesting function, 
it would be possible to add functionality to OpenAFS that requires that 
library.  It would be possible to compile the new code and distribute the 
binaries, as long as the source code for the relevant parts of both 
packages were made available.  It would even be possible to include the 
entire source for the library as part of the OpenAFS distribution (which 
already includes other standalone components covered by other licenses). 
And, it works in the reverse direction, too -- OpenDCE could use libraries 
from OpenAFS.

What would not be possible would be to combine bits of code from each 
distribution to produce a single work, because that combined work would be 
covered by both licenses.  So, picking up cache management code from 
OpenAFS and dropping it into OpenDCE would not work.




That said, there are other interesting possiblities.  OpenAFS has pretty 
good CVS history, and in many cases we know exactly who contributed what 
code.  This is particularly true for things that are likely to be of the 
most interest to OpenDCE early in its life, like configure tests, linux26 
syscall stuff, and so on.  I expect in many cases those authors would be 
willing to contribute their code as-is to OpenDCE, under whatever license 
is needed.  There are already several cases where we share code with Arla 
in this way.


> Secondly, I know this is a rather drastic proposal, but is it time to
> consider splitting the cache manager out of individual filesystem clients?

That _is_ drastic.  Such a thing would need to be cross-platform and have a 
clean, well-defined interface that could be used for multiple filesystems. 
It would also be necessary to be pretty careful about the licensing issues, 
so we don't end up with something we can't use.

Note I'm not saying this is a bad idea, just a lot of work.



> Finally, I know Derrick Brashear has been talking about building
> multiprotocol fileservers for a long time.  This seems like a very
> interesting project, and a great way to combine efforts.  But, what
> licensing impediments must be overcome to make this a reality?

Actually, I think this is actually pretty easy from a licensing standpoint. 
Both AFS and DFS have fairly well-defined protocols, with multiple 
implementations (some better than others).  As long as the protocols are 
well-enough documented, it should be possible to write independent, 
interoperable implementations.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA