From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-15 18:46:17
At 05:47 PM 11/14/2004, Aaron W. LaFramboise wrote:
>While this isn't an issue to me personally, there are a great number of
>users for which MSLU is unacceptable. For whatever reason, MSLU has
>rather stringent redistribution terms that are significantly more strict
>than the BSL, and mutually incompatible with many open source licenses,
>including the GPL.
>I would recommend avoiding using MSLU if possible because it will stymie
>adoption of the library by certain catagories of users, and will
>possibly cause unintentional infringement or misunderstanding. It also
>undermines the intentions of the BSL.
>Due to these problems, at least one project has attempted to reimplement
>MSLU under a more friendly license, such as the so-far incomplete MZLU
>from Mozilla. The open source libunicows replaces Microsoft's
>pseudoimport library, and will dynamically use with MSLU or MZLU,
>depending on what is availible at load time.
Boost wouldn't be the entity redistributing the helper code, so that
reduces the problem somewhat.
>However, if only a small number of functions are needed, which I suspect
>would be the case, it might be best to eliminate this problematic
>dependency entirely, and dynamically resolve the wide functions as
>needed, using appropriate fallback functionality if they are
>unavailible. The functionality could probably be encapsulated
>transparently within some sort of helper class.
I'm just not sure how much effort boost developers would be willing to put
in to accommodate legacy operating systems which already have workarounds
available from several sources. The issue may be moot anyhow. If Win9X is
treated as a dual wide/narrow system (which we may do anyhow), and a
program only uses narrow paths, then the wide API functions will never be
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk