Re: [boost] License of endian and limits in Boost detail

Subject: Re: [boost] License of endian and limits in Boost detail
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-03-18 10:10:10

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Philip Bennefall
> Sent: Sunday, March 17, 2013 9:31 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] License of endian and limits in Boost detail
> 
> 
> ----- Original Message -----
> From: "Rene Rivera" <grafikrobot_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Thursday, March 14, 2013 2:45 AM
> Subject: Re: [boost] License of endian and limits in Boost detail
> 
> 
> On Tue, Mar 12, 2013 at 4:31 AM, John Maddock <boost.regex_at_[hidden]>wrote:
> 
> > Are there any news on what might be done regarding this? I looked a little
> >> more into it today, and it appears as though something as trivial as
> >> boost/circular_buffer.hpp pulls in the whole config folder with
> >> endian.hpp
> >> and limits.hpp so I am avoiding using them altogether for now in this
> >> project.
> >>
> >
> > I've just removed detail/limits.hpp and edited boost/limits.hpp to not
> > refer to it.
> >
> > We'll see if anyone complains I guess.
> >
> > endian.hpp is harder to know what to do with: there's no actual code in
> > there, it's more like the accumulated wisdom of multiple Boosters plus bug
> > reports etc.  I'm actually not sure why SGI's copyright ended up in there:
> > looks like when Caleb Epstein originally wrote that header he borrowed the
> > "wisdom" from limits.hpp and so put SGI's copyright on it.  Any ideas on
> > how we would go about creating a clean version?  If someone described the
> > logic in words, and someone else wrote a new header from the description
> > would that do it - or am I deceiving myself?
> If someone describes the general aspects of the detection I can see about
> adding it to my Predef library. With the eventual expectation that the
> library is going to make it into Boost soon obviously. But if it doesn't it
> would be then OK to steal the code into Boost without the library.. I could
> also do some research into doing the detection entirely on my own. But that
> would take more time.
> 
> Hello,
> 
> For my part, I would be most greatful to anyone willing to spend the time to
> correct this problem. For me, it's a bit of a Boost usage showstopper
> because pretty much every library includes endian.hpp. While my knowledge on
> the subject of detecting endianness is quite limited, I would be more than
> happy to do anything I can to help resolve the situation.

I agree that getting rid of this 'feature' is an important issue. 

We really should ensure that Boost licencing 'does what is says on the tin' - being Boost licensed.

John's proposal and then add to the proposed Predef library sounds a good way forward.

Actually I suspect that there is really only one way to do this task - whatever the actual macro
variable names used in the code.

Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]