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) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
