I'm curious as to the to boost policy in a situation similar to the following: Given the serialization library in its current state. Someone creates a special kind of archive - called edit_[io]archive which works something like this: // create/obtain a tree control suitable for hierarchical data editing ?::archive_tree_control tc(..); // create an edit archive boost::archive::edit_oarchive eo(tc); // initialize the tree control with the data as described by serialization eo << my_data; ... user edits tree control - when he's done and hit OK // reload data from tree control // create an input archive from the tree control boost::archive::edit_iarchive ei(tc); ei >> my_data; This is concievably useful application. Now when it comes the implementation: // common interface for all GUI platforms/libraries namespace ? { class archive_tree_control{ ... }; } // ? // MFC implementation #include <stdafx.h> // MFC headers which included windows.h and a lot more namespace ? { class archive_mfc_tree_control : // refinement of MFC standard control public archive_tree_control, public CTreeControl { ... }; }//? Assuming that something like this could be made to work - where would it fit into boost - if at all. It depends upon proprietary code - MFC - Hmmm but then all our code depends upon compilers - many of which are proprietary code. It depends upon a proprietary libary interface - MFC - Maybe that would be the issue - but the code itself would be subject to a boost license. I don't see a way to test it in a way that is compatible with boost practices. Its inherently non-portable. That might be the deal breaker. I guess the question would be: What is the status of code which follows the boost license but depends upon code which doesn't follow the boost license? Robert Ramey