While you may fork the code base, you may not fork the AFS3 wire protocols. If you decide to implement your own extensions to AFS3 you must follow the rules of the AFS3 standardization and RPC registration processes. If you choose not to follow those rules, then you must implement your own wire protocol that will not interfere with AFS3 clients and servers.
While the approach you describe below might be sufficient for your personal needs, it is unlikely that it would be acceptable to OpenAFS. Jeffrey Altman On 9/10/2012 12:33 AM, Troy Benjegerdes wrote: > 1) replace kernel filesystem type of 'afs' with 'tfs'' > 2) expand all 32 bit IP address data structures to 128 bits > 3) change sockaddr() etc calls to INET6 > 4) develop ipv4 afs to ipv6 tfs proxy server > 5) kernel module housekeeping to allow openafs.ko and tfs.ko to > be loaded at the same time to allow clients to mount /afs using > legacy OpenAFS, and /tfs moving forward. > > Is there anything else I'm missing (besides the flamewar that > will probably follow regarding the name change?) > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel >
signature.asc
Description: OpenPGP digital signature
