Glossary FDLnotes

Multiple FDLs

As was pointed out in Logical Libraries, development of certified content (as opposed to mere use of extant content), requires the use of the FDL process since the Certificates are "owned" by the FDL.

It would not long be tolerable, however, for multiple developers to have to yoke themselves together to a single process. After all, different parties will want to work at least temporarily in isolation, or may want to maintain independent FDLs. Here is one scenario. Periodically a user connects to a large shared FDL and downloads parts to be developed onto a laptop computer. Later they want to contribute the developed content back to the large FDL. Here is another. For purposes of reliability or speed, an entire FDL is copied, then both the original and the copy are developed, and eventually both parties want to combine their content. A combination of these two: a user wants to draw material from two divergent FDLs that have not (yet) been combined, and do some local development, eventually making it available for general use.

In all these scenarios the situation is one in which there is a distributed repository, namely all the FDL repositories one can connect to, which is relative to time and circumstance. But these repositories are still distinct because each repository is responsible for its own certificate objects and cannot be responsible for the others'. This is rather like a real library system (ie, one with real books) made of individual libraries that control their own premises, but cooperate as providers of content. The libraries cooperate but are independent; this is fortunate because sometimes a library burns down or loses books or mismanages its records. It is the mismanagement of certificates that is of particular concern to our ambitions for "logical" libraries.

The bottom line is that the certificates in the source FDL cannot be simply copied as certificates into another FDL. What is possible is for an FDL to create its own certificate containing the foreign certificate's content, and indicating the foreign source of that content. Let us call this kind of certificate a "borrowed" certificate. Note that the new "borrowed" certificate will have different meaning from the original, although the content of the foreign original is extractable from it. Parties that trust the source of the certificate can use the borrowed certificates in lieu of original local certificates, and parties that don't can ignore them or attempt to have fresh local certificates built with the same content as the foreign certificate. To summarize, a borrowed certificate is a certificate attesting to the fact that the content was taken from another specific supposed FDL process, and as such, whatever certification policies appear to be indicated by the content, and are purported to have been enforced by the foreign FDL process, are not adopted by the borrowing FDL.

The local re-establishment of borrowed certificates, ie the attempt to create equivalent native certificates, might be a good use of spare cycles in the background; here's a place where the "objective" certificates mentioned in Logical Libraries pay off. On the other hand, managers of several large FDLs may aspire to collective trustworthiness, going to great pains to assure users of reliability of communication with them and of their faithful implementation of certificates, and simply "borrow" each other's claims without locally recertifying them except upon explicit demand. See Borrowed Certificates for elaboration. IF YOU CAN SEE THIS go to

Glossary FDLnotes