[OpenAFS-devel] IBM public license code (from OpenAFS) in samba/examples/nss ok?

Jeffrey Hutzelman jhutz at cmu.edu
Thu Aug 26 15:46:54 GMT 2004

On Thursday, August 26, 2004 16:29:39 +0200 Volker.Lendecke at SerNet.DE wrote:

> Attached find a patch to Samba that implements a rather AFS-specific
> thing: A proxy that speaks the AFS ptserver protocol as a server, and
> redirects the queries to a locally running winbind. I'd like to commit
> that to Samba, so that I don't have to patch my customer's special RPM.

Hm; that looks interesting.  I see that your patch introduces dependencies 
on AFS libraries, and not in an entirely good way.  Particularly...

- You do not need libuafs at all.  This library contains a complete
  standalone user-mode cache manager, for use in software that accesses
  AFS directly, bypassing the cache manager completely (for example,
  the apache direct-to-afs module).

- You must choose pthreads or LWP; you cannot use both.
  For LWP, use -lrxkad -lrx -llwp -lcom_err
  For pthreads, use -lafssrpc

- Do not include ptint.cs.o in the server; it is not necessary.
  The .cs.o file contains client-side RPC stubs.

Also, your patch seems to include a copy of ptint.cs.h.  This is generated 
by rxgen; it is not a source file.

I have not read your code in detail, so I'm not going to comment at this 
time on whether the implementation is reasonable or on whether it appears 
to be consistent with the behaviour of a real ptserver or with what passes 
for a protocol spec.  However, I will point out that for RPC's you do not 
wish to support, it is generally fine to just return RXGEN_OPCODE.

> The problem are the 3 files ptint.xg and ptopcodes.h which are rather
> verbatim copies from OpenAFS. ptint.xg is the AFS counterpart of an IDL
> file, ptopcodes.h is just are constants. Probably I would have been able
> to reproduce them from textual documentation, but esp. for the IDL file
> this is somewhat nasty.

For a couple of years now I've been maintaining a registry of AFS protocol 
constants, including RPC opcode numbers (http://grand.central.org/numbers); 
a side goal is to eventually completely document the various AFS protocols. 
To that end, it has always been my intent to provide .xg files and opcode 
headers which can be freely used by any AFS implementation.

At present, this has been done for a grand total of one protocol, and not 
the one you care about.  However, the ptserver protocol seems a perfectly 
reasonable next choice.

> They are licensed under the IBM public license, as the comment states:
> /*
>  * Copyright 2000, International Business Machines Corporation and others.
>  * All Rights Reserved.
>  *
>  * This software has been released under the terms of the IBM Public
>  * License.  For details, see the LICENSE file in the top-level source
>  * directory or online at http://www.openafs.org/dl/license10.html
>  */
> I don't understand the legal stuff enough to be really sure it is ok to
> check this into a GPL project.

Well, I'm certainly not going to interpret the IBM Public License or the 
GPL for you.  You and/or the Samba project should get your respective 
lawyers to do that.  However, I can tell you that any .xg files and opcode 
lists I prepare for distribution as part of the assigned numbers registry 
will have licenses which permit them to be used in GPL'd software.

In any case, I'd suggest you also consider any potential interactions 
between the license on your code and on code you plan to link with, 
including OpenAFS libraries and OpenSSL.

> What do you think? Would it be possible to get an "official" answer from
> IBM? (duck)...

I very much doubt that IBM will do any such thing.  At best, they're in a 
position to speak for themselves and say "it's OK with us".  They can't 
speak for the other contributors to OpenAFS, and they certainly can't speak 
for Samba.

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

More information about the samba-technical mailing list