From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-26 11:06:00
>// (C) Copyright 2002 Robert Ramey - http://www.rrsd.com . Permission to copy,
>// use, modify, sell and distribute this software is granted provided this
>// copyright notice appears in all copies. This software is provided "as is"
>// without express or implied warranty, and with no claim as to its suitability
>// for any purpose.
In included the above boiler plate that I copied from other boost code.
>Well, since you are the author, unless you revoke your copyright by placing
>it in the public domain, or giving it to someone else, you have the final
>say in what happens to the library. What you can't do is prevent someone from
>making a new version of your library based on the features they want, since
>the license requirements allow for this possibility.
>> Once I give it to boost, its not really mine anymore. I recognize that this
>> is how it has to be.
>I don't see any reason why you would give up your copyright. You simply
>need to have a conforming license. My understanding is that Boost
>recognizes and values the contribution of library authors, and works to
>protect their donation to the community by requiring a clearly stated
>copyright/license in submitted libraries.
Hmmm - I honestly never gave this any thought. But once one has made the software
source public along with the language above, then what possible value could
the copyright have? I saw the above language as identical to putting the
code in the public domain. I still don't see any practical difference.
In reqards to serialization, I would hope that those who have expressed and
interest in related topics, e.g. reflection and XML. Would implement there
ideas and submit them to boost. Included in this would necessarily be
proposed changes in the serialization library to required to support these
new packages. These changes would be considered in conjunction with
the new package. Thay way, only things would be added after it was
deemed that they were truely necessary and useful. I believe it is
impossible to anticipate the best way to alter the library to support
a future application which is yet to be designed.
By the way, the situation with shared_ptr is an example of this. I asked
Peter Dimov to change a member variable from private to public so that
my implementation of serializaiton of shared_ptr would work. He refused
to do so. I presume that he didn't want to be changing his library to
accomodate something that might not even be included in boost. So
I created a local copy with just that one change and left the shared_ptr
serialization as an example. If serialization is accepted into boost
I would expect this situation would eventually be remedied. That's why
I havn't made an issue of it. This is consistent with my reluctance to
add features to support speculative designs of future enhancements.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk