Hi, The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf I have volunteered to look into modifying the Boost smart pointers to match the TR1 specs and the libstdc++ coding standards. I realise I can modify the files and include them under the terms of the Boost licence, but the last Boost code to be used in libstdc++ (the concept checks) were licensed under the GPL. I believe that was something Jeremy Siek (as copyright holder) allowed specially: http://gcc.gnu.org/ml/libstdc++/2001-04/msg00050.html Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources? It would probably require licensing them as GPL, which is where I imagine some people might have reservations. That wouldn't affect the copies in the Boost tree, of course. Allowing this would greatly speed up the process of adding TR1 features to libstdc++ and tracking the draft TR as it evolves. I am prepared to rewrite the smart pointers without using Boost code if necessary, but would obviously prefer not to, when the Boost implementations are the reference ones that were used for the TR1. I eagerly await responses, as whether I have to rewrite the classes or not will have quite an impact on my free time :-) jon -- "The following story is true. By which I mean false. It's all lies. But they're entertaining lies. And in the end, isn't that the real truth. The answer, is no." - Leonard Nimoy, in "The Simpsons"
Jonathan Wakely wrote:
The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf
[...] I would really prefer to see a more general implementation of TR1 that is not only usable for GCC. It has often been suggesteded in this group to implement such a library as a part of boost, and IMO this would also be the right place for it (IIRC, for some TR1 libraries a simple configuration of the namespace could be sufficient) Of course, every compiler implementer is free to write his own TR1 library now, but I'm not sure if this makes much sense! Furtermore, it could be a good decision to wait another 2 weeks until TR1 has reached its final state. Stefan
"Stefan Slapeta" <stefan@slapeta.com> wrote in message news:ckeh1l$r65$1@sea.gmane.org...
Jonathan Wakely wrote:
The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf
[...]
I would really prefer to see a more general implementation of TR1 that is not only usable for GCC. It has often been suggesteded in this group to implement such a library as a part of boost, and IMO this would also be the right place for it (IIRC, for some TR1 libraries a simple configuration of the namespace could be sufficient)
Of course, every compiler implementer is free to write his own TR1 library now, but I'm not sure if this makes much sense!
Dinkumware is producing an implementation of TR1 from scratch. In the process, Pete Becker has apparently discovered some small problems with the specifications and some improved implementation techniques, so I don't think independent implementations are such a bad idea.
Furtermore, it could be a good decision to wait another 2 weeks until TR1 has reached its final state.
Naturally.
Stefan
Jonathan
On Mon, Oct 11, 2004 at 12:32:42PM -0600, Jonathan Turkanis wrote:
"Stefan Slapeta" <stefan@slapeta.com> wrote in message news:ckeh1l$r65$1@sea.gmane.org...
Jonathan Wakely wrote:
The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf
[...]
I would really prefer to see a more general implementation of TR1 that is not only usable for GCC. It has often been suggesteded in this group to implement such a library as a part of boost, and IMO this would also be the right place for it (IIRC, for some TR1 libraries a simple configuration of the namespace could be sufficient)
FWIW I split the shared ptr bits across std::tr1 and ::__gnu_cxx (the libstdc++ namespace for non-std stuff) but we've now decided to just leave everything in std::tr1, including the parts from boost::detail.
Of course, every compiler implementer is free to write his own TR1 library now, but I'm not sure if this makes much sense!
For proprietary libraries where it matters that the code is owned by the library copyright holder I can see it makes sense.
Dinkumware is producing an implementation of TR1 from scratch. In the process, Pete Becker has apparently discovered some small problems with the specifications and some improved implementation techniques, so I don't think independent implementations are such a bad idea.
True. There would be nothing to stop libstdc++ doing an independent implementation later, but for now I think the idea is to put together as much as possible, to have _something_ there to experiment with.
Furtermore, it could be a good decision to wait another 2 weeks until TR1 has reached its final state.
Naturally.
I'll certainly be working from the final report when it's available (though I didn't realise it was due that soon). The TR1 code we're working on will be in the libstdc++ CVS repository, but won't be part of any GCC release before the TR is finalised. Thanks for the input, and thanks again to those who have replied already giving permission, jon -- "Until they become conscious they will never rebel, and until after they have rebelled they cannot become conscious." - 1984, George Orwell
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote:
On Mon, Oct 11, 2004 at 12:32:42PM -0600, Jonathan Turkanis wrote:
Dinkumware is producing an implementation of TR1 from scratch. In the process, Pete Becker has apparently discovered some small problems with the specifications and some improved implementation techniques, so I don't think independent implementations are such a bad idea.
True. There would be nothing to stop libstdc++ doing an independent implementation later, but for now I think the idea is to put together as much as possible, to have _something_ there to experiment with.
I definitely didn't mean to imply that *all* implementations should be from the ground up. The Boost implementations are pretty good ;-) At some point, though, I'd like to see at least one other independent implementation, in addition to Dinkumware -- preferably more. Jonathan
Jonathan Turkanis wrote:
I definitely didn't mean to imply that *all* implementations should be from the ground up. The Boost implementations are pretty good ;-) At some point, though, I'd like to see at least one other independent implementation, in addition to Dinkumware -- preferably more.
Metrowerks?
On Oct 12, 2004, at 1:12 PM, Jonathan Turkanis wrote:
I definitely didn't mean to imply that *all* implementations should be from the ground up. The Boost implementations are pretty good ;-) At some point, though, I'd like to see at least one other independent implementation, in addition to Dinkumware -- preferably more.
Buy Metrowerks Pro 9 and you will see it. :-) -Howard
"Howard Hinnant" <hinnant@twcny.rr.com> wrote in message news:518B2A47-1C7C-11D9-92A6-003065D18932@twcny.rr.com...
On Oct 12, 2004, at 1:12 PM, Jonathan Turkanis wrote:
I definitely didn't mean to imply that *all* implementations should be from the ground up. The Boost implementations are pretty good ;-) At some point, though, I'd like to see at least one other independent implementation, in addition to Dinkumware -- preferably more.
Buy Metrowerks Pro 9 and you will see it. :-)
For some reason I thought it used parts of the Boost code base. I gather I was wrong? Jonathan
On Oct 12, 2004, at 6:56 PM, Jonathan Turkanis wrote:
Buy Metrowerks Pro 9 and you will see it. :-)
For some reason I thought it used parts of the Boost code base. I gather I was wrong?
I implemented it from the TR1 spec. Peter Dimov was a tremendous help though (jeeze that guy is smart! :-) ). And as Peter recently pointed out:
But legalese aside, the most important part of the implementation are the tests, anyway. ;-)
I'd agree 100%, but without the smiley. The shared_ptr/weak_ptr spec implies some of the most subtle code I've ever tried to implement. Peter's tests really saved the day. -Howard
"Howard Hinnant" <hinnant@twcny.rr.com> wrote in message news:197E7641-1CA8-11D9-92A6-003065D18932@twcny.rr.com...
On Oct 12, 2004, at 6:56 PM, Jonathan Turkanis wrote:
Buy Metrowerks Pro 9 and you will see it. :-)
For some reason I thought it used parts of the Boost code base. I gather I was wrong?
I implemented it from the TR1 spec.
Don't get me wrong -- I knew you could do it yourself ;-)
Peter Dimov was a tremendous help though (jeeze that guy is smart! :-) ). And as Peter recently pointed out:
But legalese aside, the most important part of the implementation are the tests, anyway. ;-)
I'd agree 100%, but without the smiley. The shared_ptr/weak_ptr spec implies some of the most subtle code I've ever tried to implement.
I'm surprised -- but I probably shouldn't be. To be honest, I haven't used weak pointers since I programmed in Java. Each time I've thought I needed weak_ptr I've always ended up adopting some other solution. But now you have me very intrigued.
-Howard
Jonathan
On Oct 11, 2004, at 1:29 PM, Jonathan Wakely wrote:
Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources?
Speaking only for myself, I didn't realize my fingerprints were on any of these. If they really are somewhere, my permission is given. I've already reimplemented these for Metrowerks and that's the only code I can't share. Btw, it isn't in the TR1, but you might consider: shared_ptr<T[]> and weak_ptr<T[]> as a conforming extension. -Howard
On Mon, Oct 11, 2004 at 02:36:16PM -0400, Howard Hinnant wrote:
On Oct 11, 2004, at 1:29 PM, Jonathan Wakely wrote:
Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources?
Speaking only for myself, I didn't realize my fingerprints were on any of these. If they really are somewhere, my permission is given. I've already reimplemented these for Metrowerks and that's the only code I can't share.
// // boost/checked_delete.hpp // // Copyright (c) 2002, 2003 Peter Dimov // Copyright (c) 2003 Daniel Frey // Copyright (c) 2003 Howard Hinnant // Although I'm not sure I'll use that file. Thanks for the permission anyway - it's very much appreciated.
Btw, it isn't in the TR1, but you might consider: shared_ptr<T[]> and weak_ptr<T[]> as a conforming extension.
I'll look into it, thanks for the suggestion. Thanks to everyone else who's generously said yes. jon -- "The man that hath no music in himself, Nor is not mov'd with concord of sweet sounds, Is fit for treasons, stratagems, and spoils; The motions of his spirit are dull as night, And his affections dark as Erebus. Let no such man be trusted." - William Shakespeare, "The Merchant of Venice"
Jonathan Wakely wrote:
On Mon, Oct 11, 2004 at 02:36:16PM -0400, Howard Hinnant wrote:
On Oct 11, 2004, at 1:29 PM, Jonathan Wakely wrote:
Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources?
Speaking only for myself, I didn't realize my fingerprints were on any of these. If they really are somewhere, my permission is given. I've already reimplemented these for Metrowerks and that's the only code I can't share.
@Howard: Your fingerprints come from the fix we worked out to make checked_delete work for the CW IIRC. @Jonathan: You have my permission, too, to use checked_delete.hpp in the GCC sources. Although I nearly missed the fact that you meant me, as I'm not an author of SmartPtr - checked_delete is IMHO independent, just used by SmartPtr. :) Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
Jonathan Wakely wrote:
On Mon, Oct 11, 2004 at 02:36:16PM -0400, Howard Hinnant wrote:
On Oct 11, 2004, at 1:29 PM, Jonathan Wakely wrote:
Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources?
Speaking only for myself, I didn't realize my fingerprints were on any of these. If they really are somewhere, my permission is given. I've already reimplemented these for Metrowerks and that's the only code I can't share.
// // boost/checked_delete.hpp // // Copyright (c) 2002, 2003 Peter Dimov // Copyright (c) 2003 Daniel Frey // Copyright (c) 2003 Howard Hinnant
Daniel Frey and Howard Hinnant "own" the two lines that look like: (void) sizeof(type_must_be_complete); which are needed only on some specific versions of the Metrowerks compiler with -iso-templates on.
Jonathan Wakely wrote:
Hi,
The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf
I have volunteered to look into modifying the Boost smart pointers to match the TR1 specs and the libstdc++ coding standards.
I realise I can modify the files and include them under the terms of the Boost licence, but the last Boost code to be used in libstdc++ (the concept checks) were licensed under the GPL. I believe that was something Jeremy Siek (as copyright holder) allowed specially: http://gcc.gnu.org/ml/libstdc++/2001-04/msg00050.html
Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources? It would probably require licensing them as GPL, which is where I imagine some people might have reservations. That wouldn't affect the copies in the Boost tree, of course.
Allowing this would greatly speed up the process of adding TR1 features to libstdc++ and tracking the draft TR as it evolves. I am prepared to rewrite the smart pointers without using Boost code if necessary, but would obviously prefer not to, when the Boost implementations are the reference ones that were used for the TR1.
I eagerly await responses, as whether I have to rewrite the classes or not will have quite an impact on my free time :-)
I (Peter Dimov, also speaking on behalf of Multi Media Ltd) hereby grant you permission to use my contributions to Boost in the TR1 implementation in libstdc++. But legalese aside, the most important part of the implementation are the tests, anyway. ;-) Rewriting shared_ptr isn't that hard, really, once you know what to aim for.
At 01:29 PM 10/11/2004, Jonathan Wakely wrote:
Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources? It would probably require licensing them as GPL, which is where I imagine some people might have reservations.
You have my permission, as long as the licence is either the Boost licence or the GPL. For any other license, contact me privately. --Beman Dawes
Jonathan Wakely wrote: <snip>
Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources? It would probably require licensing them as GPL, which is where I imagine some people might have reservations. That wouldn't affect the copies in the Boost tree, of course. <snip>
libstdc++ is not solely distributed under the GNU GPL - if it was, every program built with it would have to be distributed under GPL as well. It actually has a "runtime exception" <http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html> which means (roughly) that the library may be used by any program distributed under any terms. You need to ensure that the copyright holders are aware of what this additional clause says before getting their permission. Ben.
Ben Hutchings wrote: [...]
libstdc++ is not solely distributed under the GNU GPL - if it was, every program built with it would have to be distributed under GPL as well. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nonsense (if you mean distribution of "copies" [17 USC 101]; not licensing exclusive rights to original and derivative "works"... which must be done under the terms of the GPL and only the GPL; compilation-vs-derivative distinction aside for a moment). Being a mere copyright license (not a contract), the GPL can't override the first sale [17 USC 109]. regards, alexander.
Alexander Terekhov wrote:
Ben Hutchings wrote: [...]
libstdc++ is not solely distributed under the GNU GPL - if it was, every program built with it would have to be distributed under GPL as well.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nonsense (if you mean distribution of "copies" [17 USC 101]; not licensing exclusive rights to original and derivative "works"... which must be done under the terms of the GPL and only the GPL; compilation-vs-derivative distinction aside for a moment). Being a mere copyright license (not a contract), the GPL can't override the first sale [17 USC 109].
You are surely aware that your idea of what requires a licence (and on which the GPL can therefore place conditions) is unusual and does not agree with the intent of most of those distributing under the GPL. I've stated what I believe to be the case and I don't wish to argue it with you. Those who are being asked to give permission for inclusion in libstdc++ can make up their own minds. Now that I think about it, I seem to remember that contributions to GCC (of which libstdc++ is part) must have their copyright assigned to the FSF. If this is correct, it would not be sufficient for copyright holders to give permission for relicencing. Can you check this, Jonathan?
Ben Hutchings wrote: [...]
You are surely aware that your idea of what requires a licence (and on which the GPL can therefore place conditions) is unusual and does not agree with the intent of most of those distributing under the GPL. I've stated what I believe to be the case and I don't wish to argue it with you.
Go read http://google.com/groups?threadm=cdujqq%24dd5%241%40vegh.ks.cc.utah.edu (Subject: Re: GPL Loophole or Not?) (I mean the entire thread) and also {the entire} Hollaar's treatise available at http://digital-law-online.com Uhmm, DMCA Section 104 Report (including testimonies) is the next step: http://www.google.com/groups?selm=40D8767D.5A830BA%40web.de http://www.google.com/groups?selm=40D872CB.BF665A1E%40web.de Reading court cases on enforceability of software licenses won't hurt either: http://www.google.com/groups?selm=410FD714.CE37FD86%40web.de Then make up your mind and believe in whatever you want. regards, alexander.
On Wed, Oct 13, 2004 at 11:33:05AM +0100, Ben Hutchings wrote:
Now that I think about it, I seem to remember that contributions to GCC (of which libstdc++ is part) must have their copyright assigned to the FSF. If this is correct, it would not be sufficient for copyright holders to give permission for relicencing. Can you check this, Jonathan?
I have a copyright assignment on file with the FSF, and all my contributions are therefore copyright FSF. I don't think this applies to code from elsewhere which is incorporated, for instance most of the STL files say "Copyright HP", "Copyright SGI" and "Copyright FSF". The Boost concept checks still contain a copyright statement from Jeremy Siek. http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices says: For an FSF-copyrighted package, if you have followed the procedures to obtain legal papers, each file should have just one copyright holder: the Free Software Foundation, Inc. You should edit the file's copyright notice to list that name and only that name. But if contributors are not all assigning their copyrights to a single copyright holder, it can easily happen that one file has several copyright holders. Each contributor of nontrivial amounts is a copyright holder. [this seems to be the situation for Boost/SGI/HP code used in GCC - jon] In that case, you should always include a copyright notice in the name of main copyright holder of the file. You can also include copyright notices for other copyright holders as well, and this is a good idea for those who have contributed a large amount and for those who specifically ask for notices in their names. But you don't have to include a notice for everyone who contributed to the file, and that would be rather inconvenient. The copyright on the original code is still held by the original authors, the copyright on the new parts of a derived work is held by the FSF. I will be sure to check this - I have no intention of removing any of the smart ptr authors rights. I don't think anyone _could_ remove their rights except the authors themselves. As I understand it (which is not in *any* way authoritative) if the authors give permission for me to use the code under the GPL (which I think amounts to dual-licensing it to me as Boost and GPL?) then I am free to modify their original code, still under the GPL. The modified version then has my copyright (which I assign to the FSF) _and_ the original authors copyright statements on. Alexander, whatever your views on whether the GPL can be upheld, you seem to be pretty knowledgable on copyright issues, have I got it even partly right? Another possibly relevant part is here: http://www.gnu.org/prep/maintain/maintain.html#External-Libraries The files from Boost could be used that way - but if it came to that I'd rewrite them (as I already have with parts, since there's no need to support compilers other than GCC in libstdc++). Ben, thanks for pointing out the GPL exception that libstdc++ uses. It was a stupid omission by me that slipped my mind. I meant to reply yesterday to say thanks but haven't sent the mail yet. I'll mail the FSF now and ask for clarification on this anyway. jon -- I would like to suggest that you not use speed, and here's why: it is going to mess up your heart, mess up your liver, your kidneys, rot out your mind. In general this drug will make you just like your mother and father. - Frank Zappa
Jonathan Wakely wrote: [...]
As I understand it (which is not in *any* way authoritative) if the authors give permission for me to use the code under the GPL (which I think amounts to dual-licensing it to me as Boost and GPL?) then I am free to modify their original code, still under the GPL. The modified version then has my copyright (which I assign to the FSF) _and_ the original authors copyright statements on.
Alexander, whatever your views on whether the GPL can be upheld, you seem to be pretty knowledgable on copyright issues, have I got it even partly right?
I think you got it right. The only question is how much of original and derivative (colloquially) work "deserves" the copyright protection. I bet that in the case of SmartPtr, when honestly applied, filtration step of the AFC test will entirely eliminate copyright protection for any decent implementation. regards, alexander.
Alexander Terekhov wrote:
Jonathan Wakely wrote: [...]
As I understand it (which is not in *any* way authoritative) if the authors give permission for me to use the code under the GPL (which I think amounts to dual-licensing it to me as Boost and GPL?) then I am free to modify their original code, still under the GPL. The modified
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
version then has my copyright (which I assign to the FSF) _and_ the original authors copyright statements on.
Alexander, whatever your views on whether the GPL can be upheld, you seem to be pretty knowledgable on copyright issues, have I got it even partly right?
I think you got it right.
Except that you don't need any license at all to create an "adaptation" under 17 USC 117 and keep it private. The precondition is just a lawful ownership of a copy. http://www.google.com/groups?selm=410F4FD4.243B2F35%40web.de (see quotation from "contu6.html") BTW, in light of 17 USC 117, I don't quite get how SCO is going to establish copyright infringement in the case against AutoZone even if AZ indeed "copied" SCO's shared libraries during migration to Linux (as SCO seems to claim)... provided that AZ still owned sufficient number of copies of SCO OpenServer or whatever bundle with libraries included. regards, alexander.
Alexander Terekhov wrote:
I think you got it right. The only question is how much of original and derivative (colloquially) work "deserves" the copyright protection. I bet that in the case of SmartPtr, when honestly applied, filtration step of the AFC test will entirely eliminate copyright protection for any decent implementation.
You'll lose that bet, IMO. Not that it matters.
participants (9)
-
Alexander Terekhov -
Beman Dawes -
Ben Hutchings -
Daniel Frey -
Howard Hinnant -
Jonathan Turkanis -
Jonathan Wakely -
Peter Dimov -
Stefan Slapeta