Robert Ramey wrote:
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: ...snip detail... Assuming that something like this could be made to work - where would it fit into boost - if at all.
It could be part of the library as an MFC specific archive class.
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.
There's no issue with that in that any user of this would have to get their own MFC license.
I don't see a way to test it in a way that is compatible with boost practices.
#ifndef HAS_MFC #endif Or simply don't include it in the regression tests. Test it yourself -- say so in the docs.
Its inherently non-portable. That might be the deal breaker.
I don't see why that's an issue. You aren't changing the core of the library to make it non-portable, just including a new feature that only happens to be useful to MFC users.
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?
We have that in several places like iostreams which utilizes zip and other libraries written with GNU licenses. As long as the library can be used without this extension (obviously the case with serialization) then it's ok to have an extension. Basically, I don't think there's an issue including it. Jeff