[waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Chad Versace]

On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote:
> On Sun, May 25, 2014 at 2:43 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> > On 25/05/14 21:35, Jordan Justen wrote:
> >> On Sat, May 24, 2014 at 12:28 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> >>> * Library dependencies, etc. (low priority)
> >>> libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the dependency,
> >>> ship them in the zip or leave it to the user/dev ?
> >>>
> >>>   Library:
> >>>     libgcc_s
> >>>       __emutls_get_address
> >>>       __udivdi3
> >>>       __umoddi3
> >>>
> >>>   Options:
> >>>     - Static link libgcc_s, generally not bad idea
> > sigh, a bit of a typo here - the above should read:
> >
> > - Static link libgcc_s - generally _a bad_ idea
> 
> Doesn't gcc/binutils automatically do this when you compile/link?
> 
> >> What are the licensing implications?
> >>
> > That's possibly the main reason why I'm inclined to go with rework. I've never
> > been good at the legal/licensing terms.
> >
> >> I think libgcc would be covered by this exception, right?
> >> https://www.gnu.org/licenses/gcc-exception-3.1-faq.html
> >>
> >> If so, it seems like static linking might not be a problem.
> >>
> > IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no
> > gpl-incompatible software is used during the "Compilation Process", thus we
> > are "Eligible".
> 
> It sounds they only mean to prevent non-GPL compatible code from
> getting into the internals of the GCC complication process. So, in
> other words, you can't have a proprietary GCC plugin, and also use the
> exception to link to libgcc, etc.
> 
> But, it seems like even proprietary code could use the exception to
> link to libgcc as long as it was just being compiled by GCC.
> 
> >>>     - or, rework waffle ?
> >>>           Split merged_version or move to (major << 8 | minor) for the
> >>>           wcore_config_attrs_version_* helpers - will nuke the last two.
> >>>           No idea how to nuke __emutls_get_address.
> >>>
> >>>   Suggestion:
> >>>     Split to separate major/minor.
> >>>
> >>>
> >>>   Library:
> >>>      libwinpthread-1
> >>>        pthread_key_create
> >>>        pthread_mutex_lock
> >>>        pthread_mutex_unlock
> >>>        pthread_once
> >>>        pthread_setspecific
> >>>
> >>>   Options:
> >>>      - Static link
> >>
> >> What are the licensing implications?
> >>
> >> It doesn't look as good as the libgcc case.
> >>
> > The library is a combination of X/MIT and 3-clause BSD. Which afaics is rather
> > vague on the topic of static linking the library and distribution of the final
> > binary(ies). My guess is that we ought to be safe but IANAL.
> 
> This wasn't my concern. I was concerned the library might have been
> GPL licensed, and thus the waffle DLL wouldn't be usable with a
> proprietary application.
> 
> Chad, would you be okay with releasing the windows waffle DLL and
> noting that it is partially covered by X/MIT, 3-clause BSD and
> 2-clause BSD?


If Waffle needs a stacked license to support Win32, that's ok with me.
Liberal licenses in the BSD, MIT, and Apache family are all acceptable.

I am not a lawyer either, so I do not know if statically linking the
parts you speak of are safe to do so. I think you should make your
initial decision based on its technical merits. Then, after the
technical, decision is made but before you've invested too much time in
it, all of us (you, Jordan, me, Jose) should analyze any license issues.

FWIW, I prefer to avoid runtime dependency hell by statically linking
small, problematic components. But my opinion is of limited value here,
because I'm unfamiliar with the problem domain of mingw and MSVC.


> > If I understand things correctly we are safe to ship the library, as long we
> > abide the rules - include licenses, no advertisement, no liability.
> >
> >>>      - or, rebuild mingw-w64-gcc with --enable-threads=win32
> >>
> >> It sounds like Chad wouldn't be able to use the standard mingw from
> >> his distro then, right?
> >>
> > Unfortunately you are absolutely right. Rebuilding things under Archlinux are
> > easy as pie, although I'm not sure his main choice of a distribution.
> 
> I'd guess that he likely has arch running somewhere. :)
> 
> I'd still prefer a solution where this wasn't required.

I use Fedora and Archlinux. And I'm not afraid of Gentoo.