- Boost - lists.preview.boost.org

Re: Three questions about the new license
by David Abrahams 16 Feb '04

16 Feb '04

Diane, I want to clarify something you may have missed: the point in question does not concern the Boost license itself, but the way in which our source files declare the license to be applicable to them. They do not contain a copy of the license, but instead make reference to it in a comment, typically: // Copyright David Abrahams 2004. Use, modification and distribution is // subject to the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Diane Cabell <dcabell(a)law.harvard.edu> writes: > David Abrahams wrote: > >> Thanks for replying, Diane. >> > (....) >> OK, I think I understand you below, but your wording is a bit >> confusing, so I'll ask for clarification: >> >>>US copyright law only grants the author the right to control public >>> display of the work. >> >> Meaning "the right to control public display of the work is granted >> solely to the author?" > > Meaning, anyone can privately display a work without the author's > permission. There is no copy "right" to control private > displays. [There may be other laws that prevent private display, and > one of them would be the right of the patent owner to prohibit > unauthorized "use" of his invention.] Ugh I don't think we ever considered that "display" would be interpreted other than to mean "display publicly". Does that mean that in the license: Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following: "display" ought to be "display publicly"? >>>See See 17 USC 106 at >>><http://www4.law.cornell.edu/uscode/17/106.html>. Yes, if the right >>>isn't specifically granted, it is not included. >> >> Therefore, the fact that a source file doesn't specifically say that >> "display is subject to the Boost Software License" means that it isn't >> granted at all? The OP was actually concerned that leaving out >> "display" implicitly granted a right to do so. My understanding is >> that it does not. Please confirm/deny. > > Right. Leaving things out does not grant any implied > permission. However (there's always a "however"), it is not necessary > to specifically grant a right to private display [unless there are > patents involved]. I don't think we're concerned about private display. >> This brings up another possible problem, though: if the license >> grants >> certain rights to display, but the source file comment only says that >> "Use, modification, and distribution" are subject to the license, >> perhaps we're failing to grant any display rights. Probably the OP >> was right to suggest that we drop the specific mention of "use, >> modification, and distribution" from source file comments. Even if we >> *are* granting display rights as intended, why risk ambiguity on this >> point? > > It does not grant them, so there is no inconsistency. What is "it"? The license certainly does grant display rights. Are you saying that the part of the license that grants display rights isn't applicable to source files with the comment shown at the top of this message? > If, on the > other hand, you believe that _public_ display should be a right > granted to users We do. > then you should add "public display" everywhere that > you see "use, modification and distribution." This is what makes me think you might have missed the fact that "use, modification and distribution" isn't in the license itself. The suggestion is that "use, modification and distribution" be removed from source files to avoid having to repeat all the rights named in the license. > (....) >>>I'm not sure how you're using the term "file", but you can erase doubt >>>by including it specifically as suggested above. >> >> Sorry, I think I was just bringing up a linguistic technicality. >> These are all copyrightable files. The question is whether a *thing* >> can be subject to a license, or only actions that might be performed >> on that thing. That's why I suggested "licensed under ... " instead >> of "subject to ... ". > > Copyright licenses copying; patents protect operations. Since patent > rights were only recently recognized for pure software, the line is > not really clear in a lot of cases. Interpretation of the licenses > isn't just limited to the linuisitics, however, but looks at the > purpose the agreement is trying to accomplish, what people in the > trade normally intend to happen in such situations, etc. I'm not sure how to apply that information to our situation. My remark about "subject to" was akin to saying "I think you're using a noun as a verb; here's a way to phrase it that avoids grammatical problems." > Diane Cabell > Clinical Program Director > Berkman Center for Internet & Society > Harvard Law School > http://cyber.law.harvard.edu -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: Google links
by Jeff Squyres 16 Feb '04

16 Feb '04

This message was forwarded to the sysadmins of the boost list; Dave asked me to reply here on the list. I am not on the boost list; please CC me on any replies. ---------- Forwarded message ---------- Date: Fri, 13 Feb 2004 16:02:35 -0500 From: David Abrahams <dave(a)boost-consulting.com> Subject: Re: [Osl-sysadmin] Care to respond? On Thu, 12 Feb 2004, David Abrahams wrote: > This showed up on the Boost list... > All the "next in thread" type links I've seen have been internally > consistent. Unfortunately, this renumbering almost certainly means that > external references to the old URL for a given message (e.g. on another > mailing list or newsgroup) will be wrong. From what I've seen of > Google's old links, you usually get a different message, not the one you > expected and not a HTTP 404 for instance. Yup -- definitely an unfortunate side-effect. > It might have been (or still be) a good idea to invalidate completely > the old style URLS to avoid confusion. In consultation with David, we decided not to do this in order to not break all the external (non-search-engine/self-healing) links. > Better still would have been to support both the old and new numberings > in parallel, since you can't know what references exist for the old > URLs. So I thought that we had restored the old numbering, and I thought that Larry (the OSL sysadmin) had checked that. Is there something other than Google (which will eventually fix itself) that is pointing to an incorrect address? -- {+} Jeff Squyres {+} jsquyres(a)osl.iu.edu {+} Research Associate, Open Systems Lab, Indiana University {+} http://www.osl.iu.edu/

3 2

Re: Three questions about the new license
by David Abrahams 16 Feb '04

16 Feb '04

Thanks for replying, Diane. Diane Cabell <dcabell(a)law.harvard.edu> writes: > David Abrahams wrote: > >>>>Do you consider documentation to be software? I don't. >>> >>>No, I don't consider it software either :) I was asking if *in the >>>text of the license* they used the word "Software", with an uppercase >>>'s', as a shortcut for software + docs. That's because it says: >>> >>> Permission is hereby granted, free of charge, to any person or >>> organization obtaining a copy of **the software and accompanying >>> documentation** covered by this license (**the "Software"**) >> >> Now that you remind me, yes, "Software" clearly includes the >> documentation. > > Not always. Often they are treated separately. However, the clause > above ensures that they are both covered. Right. I meant that it clearly includes the documentation **in this case**. >>>>[...] >>>> >>>>>b) IIUC again, the comments we are inserting into source files >>>>> >>>>> >>>>> // Use, modification and distribution are subject to the // >>>>> Boost Software License, Version 1.0. (See accompanying file // >>>>> LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) >>>>> >>>>> >>>>> are unnecessarily verbose (and potentially dangerous). >>>> >>>>Care to elaborate on why you think it's dangerous? >>> >>>Potentially. I was just asking. My question was: the file says use, >>>modification and distribution are subject to the license. Taken >>>strictly I may interpret that only this three things are subject to >>>the license (not display, for instance). If, from a legal point of >>>view, "display" isn't one of these three things then I can display the >>>software without even reading the license. OK, I think I understand you below, but your wording is a bit confusing, so I'll ask for clarification: > US copyright law only grants the author the right to control public > display of the work. Meaning "the right to control public display of the work is granted solely to the author?" > See See 17 USC 106 at > <http://www4.law.cornell.edu/uscode/17/106.html>. Yes, if the right > isn't specifically granted, it is not included. Therefore, the fact that a source file doesn't specifically say that "display is subject to the Boost Software License" means that it isn't granted at all? The OP was actually concerned that leaving out "display" implicitly granted a right to do so. My understanding is that it does not. Please confirm/deny. This brings up another possible problem, though: if the license grants certain rights to display, but the source file comment only says that "Use, modification, and distribution" are subject to the license, perhaps we're failing to grant any display rights. Probably the OP was right to suggest that we drop the specific mention of "use, modification, and distribution" from source file comments. Even if we *are* granting display rights as intended, why risk ambiguity on this point? > >>>>One could simply say >>>>> >>>>>// Subject to the Boost Software License, Version 1.0. (See etc. etc.) >>>> >>>>I don't think a _file_ can be subject to a license, can it? The file >>>>just exists. >>> >>>Hmm... I don't know. It seems to me that the file is the *medium* >>>through which a piece of software is distributed. >> If we were to make a change like that one, I'd say "Licensed under >> the >> Boost...", just to avoid any ambiguity. >> > Whether or not any particular file is capable of copyright protection > would depend on what is contained in the file. US law distinguishes > between facts/data (not protected by copyright) and creative > expression (protectable to the extent that it is severable from the > underlying idea). If a file were just an alphabetical list of names > and addresses, it would not be considered copyrightable in the US > because that's just a bare and unoriginal set of statements of fact. > > I'm not sure how you're using the term "file", but you can erase doubt > by including it specifically as suggested above. Sorry, I think I was just bringing up a linguistic technicality. These are all copyrightable files. The question is whether a *thing* can be subject to a license, or only actions that might be performed on that thing. That's why I suggested "licensed under ... " instead of "subject to ... ". -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

shared_from_this() fails when the object was handled by an auto_ptr<object const>
by Ulrich Eckhardt 16 Feb '04

16 Feb '04

Greetings! Firstly, this is not a regression, the behaviour was present in 1.30, too. I have attached a simple program that should demonstrate the behaviour, but the core is these lines, with foo being derived from enable_shared_from_this: // 1 std::auto_ptr<foo> g(new foo); boost::shared_ptr<foo> f(g); // 2 std::auto_ptr<foo> g(new foo); boost::shared_ptr<foo const> f(g); // 3 std::auto_ptr<foo const> g(new foo); boost::shared_ptr<foo const> f(g); In all three cases, I'd expect to be able to call shared_from_this(). However, only the first two cases really work. I think it boils down to the function detail::sp_enable_shared_from_this() in the ctor of shared_ptr<> that takes an auto_ptr<>. I'm not certain if there is a fix for this and what that fix would be, but I think the problem is that the 'right' function is not taken because at one place we have a 'foo' and at the other we have a 'foo const'. BTW: I believe that a conversion from auto_ptr<T> to shared_ptr<T const> doesn't compile on VC6, but I can't test that ATM(I'm not at work). If any kind soul wants to, they could add such a conversion to the regression-tests. Same goes for volatile probably. greetings and thumbs up Ulrich Eckhardt

4 6

Re: [boost] [BGL] Interest in a random-path algorithm.
by Cromwell Enage 16 Feb '04

16 Feb '04

> On a second thought and after a bit of googling, > don't you think that > Propp-Wilson Cycle Popping Random Tree algorithm > would be more efficient ? Actually, I'm looking for more path randomness, but competitive performance/speed is definitely a minimum requirement. > The paper describing the article is at > http://dbwilson.com/ja/ > It is very well explained and > pseudo-code is clear enough to easily implement it > :) I'll read up on it when I get back from the dentist. > Cheers, > Jonathan You too. Cromwell __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

[BGL] Interest in a random-path algorithm.
by Cromwell Enage 16 Feb '04

16 Feb '04

Hi, everyone. For your informal reviewing pleasure, I've uploaded a random path algorithm with accompanying documentation at <http://groups.yahoo.com/group/boost/files/bgl_algo/make_random_paths.zip> I've stated in an earlier thread that I was working on a multi-state-mazes project. Obviously the ability to create random underlying paths could give the application high reusability value. It's my hope that other developers here will also find use for this algorithm in their own projects. Feedback appreciated! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 2

Re: [boost] Re: 1.31.0 regressions
by Reece Dunn 16 Feb '04

16 Feb '04

Aleksey Gurtovoy wrote: >Beman Dawes writes: > > All of our formats are also painfully slow on less than broadband > > connections if you try to drill down to see a specific failure. > >They are slow even on broadband. That page definitely needs to be >split, somehow. Would it not be possible to employ a technique like that used by the DocBook "chunking" stylesheet. This would allow you to have a HTML page for the summary and one for each of the test sets. Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

4 3

Odd TOC numbering in the BoostBook docs
by Reece Dunn 15 Feb '04

15 Feb '04

If you look at the table of contents for the boost libraries: http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/index.html there is: 8. The BoostBook Documentation Format Introduction ... I. Boost.Build v2 User Manual 9. How to use this document 10. Installation ... This seems to be a bug in the DocBook numbering system given the current chapter, section, etc layout for the Boost docs. Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

2 1

[boostbook] xsltproc using the internet?
by Ronald Garcia 15 Feb '04

15 Feb '04

Howdy, I'm trying to build the boostbook docs. Having looked through the boostbook.jam file, seems like I should get a warning message if any DTDs are going to be fetched over the internet. I set the location of the DTD and XSL files in user-config.jam to values that I *think* are correct. In any case, It appears that the command "xsl-xsltproc" is still fetching some data remotely. A) Should I be receiving a warning about this, or am I misunderstanding the boostbook jamfile B) How exactly do I make it stop? I'm trying to use the docbook-dtd and docbook-xsl information installed on my machine using a package manager (fink). If I incorrectly specify these directories, should I expect an error that specifically points this out, or general "badness" instead? Thanks, ron

3 5

RE: [boost] Re: status of wchar_t support in filesystem::path?
by Hurd, Matthew 15 Feb '04

15 Feb '04

> On Behalf Of Edward Diener > Subject: [boost] Re: status of wchar_t support in filesystem::path? > > Paul Miller wrote: > > I just started using boost recently and it seems excellent so far. > > > > One of the first classes I started using is filesystem::path, with the > > intention to use it portably on Windows, OS X, and Linux. > > > > On Windows and OS X, you can work with paths in Unicode. Presumably > > Linux still works with multi-byte characters. > > > > Is there progres toward a wchar_t-aware path? > <snip> As a philosophy, I consider boost's filesystem to be attempting to offer a portable filesystem ability, rather than being a portable interface to a file system. As it currently stands, without unicode support, it is not much use if you want to be able to deal with arbitrary file and directory names on win32 which is not a handicap if this is not its intention. For example, I could not use it for an archiving program as I must deal with the potential for unicode names and internal stream in files. It does an admirable job of dealing with your own files where you can control the naming. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0