On 04/06/14 21:18, Jose Fonseca wrote: > > > ----- Original Message ----- >> 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.veli...@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.veli...@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://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0A&s=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389 >>>>> >>>>> 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. > > FWIW, my opinion is that we shouldn't get too distracted by licensing and > what release binaries should look like. It is not something that needs to be > decided now, or ever: ultimately, that decision can be pushed to the final > user. They might prefer mingw, they might prefer msvc for easy of debugging, > or because they want to statically link, etc. > > IMHO the most important is getting waffle to build and run on Windows on some > form. > Fair enough. Curious why did this get so much attention, perhaps the option "leave it to the user/dev" was not clear enough in my original email.
-Emil > Jose > _______________________________________________ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle