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 called. Thanks, --Beman