>// (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. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
