This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Packaging O'Caml
On Thu, Aug 26, 2004 at 04:33:38PM -0400, Igor Pechtchanski wrote:
>On Thu, 26 Aug 2004, Christopher Faylor wrote:
>> On Thu, Aug 26, 2004@02:46:55PM -0400, Igor Pechtchanski wrote:
>> >On Thu, 26 Aug 2004, Williams, Gerald S (Jerry) wrote:
>> >>Igor Pechtchanski wrote:
>> >>>However, parts of it are released under the "Q Public license", which
>> >>>GNU lists explicitly as non-GPL-compatible. Does this mean an
>> >>>automatic "no" to an official Cygwin package [...] ?
>> >>
>> >>From http://cygwin.com/licensing.html: In accordance with section 10 of
>> >>the GPL, Red Hat permits programs whose sources are distributed under a
>> >>license that complies with the Open Source definition to be linked with
>> >>libcygwin.a without libcygwin.a itself causing the resulting program to
>> >>be covered by the GNU GPL.
>> >
>> >Interestingly enough, this doesn't mention cygwin1.dll, only
>> >libcygwin.a, but I may be nitpicking...
>>
>> Or, you may be missing the point. When that sentence was written you
>> couldn't do something like "gcc -o foo foo.c /bin/cygwin1.dll". You
>> had to "gcc -o foo foo.c -lcygwin".
>>
>> The act of linking something with your program is part of what causes
>> the GPL to become active. Including pieces from libcygwin.a into your
>> program is part of what exercises the GPL.
>>
>> Other methods of linking are not covered by this generous exception.
>
>Huh? So, for example, if one builds a program that uses, say,
>cygncurses7.dll (by linking with /usr/lib/libncurses.dll.a), which, in
>turn, uses cygwin1.dll, that program cannot be released under any license
>that's incompatible with GPL?
Huh? right back at you.
When you build a program using gcc on cygwin, you link in libcygwin.a
unless you specifically tell gcc not to do so. If you do not link in
libcygwin.a then either 1) you are not building a cygwin program, or you
are 2) inexplicably linking using just the cygwin1.dll directly (which
probably wouldn't work anyway). In either case you would not be covered
by the license exception. In the first case it would hardly matter and
in the second case, it is just an artifact of the fact that linking
directly to the dll didn't work when the licensing words were written.
I don't know what libncurses has to do with anything unless libncurses
has its own licensing arrangements which could supersede cygwin's.
Obviously the cygwin dll can't impose it's own notion of acceptable
licensing if another package's terms are more stringent.
If you are postulating that it could be somehow possible to build a DLL
which links with cygwin and is then usable in a mingw application then,
yes, the GPL exception would not apply if you follow the strict wording.
It also wouldn't necessarily apply if you dynamically loaded cygwin
although, IIRC, the jury is still out on whether dynamic loading should
excersize the GPL or not.
>> >> IANAL, but the Q Public License is listed on the OSI web page, so there
>> >> don't appear to be any legal restrictions -- some Cygwin packages use
>> >> different open source licenses already.
>> >>
>> >> Or have there been policy changes for new Cygwin packages that I'm not
>> >> aware of?
>> >
>> >What threw me off was this sentense on the GNU GPL licensing page
>> >(<http://www.gnu.org/licenses/license-list.html>):
>> >
>> > Since the QPL is incompatible with the GNU GPL, you cannot take a
>> > GPL-covered program and QPL-covered program and link them
>> > together, no matter how.
>>
>> Since cygwin has an exception to the GPL, this section is potentially
>> irrelevant.
>
>Yep, that's what I said below.
No, you seemed to be implying that the GPL automatically kicks in when
that isn't necessarily correct.
>> >However, it seems I didn't read the document carefully enough, as it goes
>> >on to say
>> >
>> > However, if you have written a program that uses QPL-covered
>> > library (called FOO), and you want to release your program under
>> > the GNU GPL, you can easily do that. You can resolve the conflict
>> > for your program by adding a notice like this to it:
>> >
>> > As a special exception, you have permission to link this program
>> > with the FOO library and distribute executables, as long as you
>> > follow the requirements of the GNU GPL in regard to all of the
>> > software in the executable aside from FOO.
>> >
>> >which is almost exactly what you quoted from the Cygwin licensing page.
>> >So I guess we're ok. As soon as I work out the packaging bugs, I'll ITP
>> >O'Caml.
>>
>> No, it is not the same thing. The exception in the cygwin licensing
>> allows other licenses to still have effect as long as they adhere to
>> the open source definitions mentioned. The GPL doesn't trump these
>> licenses, although if you adhere to the GPL, then that's all the
>> better.
>
>Ah, you're right, the above quote is the inverse of that on the Cygwin
>licensing page. However, from the earlier discussion, it does seem like
>releasing the Cygwin binary of O'Caml won't conflict with the terms of
>Cygwin licensing. Am I correct in my interpretation?
If the QPL is acceptable as per the dictates of the cygwin exception,
then yes.
It really doesn't matter anyway. You are going to be releasing sources
in compliance with the GPL. The question would be whether someone else
can then take the binaries that you produced and just provide them under
the rules of the QPL. It's unlikely that anyone would do that, IMO.