Re: [boost] hypothetical question regarding boost policy

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-06-24 15:03:44

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