Re: Removal of support for GCC hosted on UWIN

Re: Removal of support for GCC hosted on UWIN

[Axel Kittenberger]

> It's only when you do it the other way around the GPL comes into
> affect;
> 
> If you have a commercial program and link with a GPL library, then
> it's a violation of the GPL if the commercial program is not GPL.
> 
> I am very interested in your reasoning about this;  Any change you can
> point me out to the information/person on which you base your
> statement?

Okay to add to the debatte...

As far I understood it you also cannot link a GPL application with an
commercial librabray.

However if you are the Author (Copyright holder) of your GPL application
you can simply add an exception to the license to allow linking to this one
(or more) specific 
A year ago or so I pestered the FSF exactly regarding this :)

Unfortunally I lost the exact disclamer template...


-- 
Sent through GMX FreeMail - http://www.gmx.net

Re: Removal of support for GCC hosted on UWIN

[Florian Weimer]

Axel Kittenberger <Anshil@gmx.net> writes:

> As far I understood it you also cannot link a GPL application with an
> commercial librabray.

Don't use 'commercial', please.  Use 'non-free'.

| However, as a special exception, the source code distributed need not
| include anything that is normally distributed (in either source or
| binary form) with the major components (compiler, kernel, and so on)
| of the operating system on which the executable runs, unless that
| component itself accompanies the executable.

If U[/]WIN is the host system, I don't see the point.  Its libraries
fall almost certainly in this category.  Maybe the U/WIN license
prohibits redistribution, but this is a different story.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: Removal of support for GCC hosted on UWIN

[dewar]

Incidentally there is almost no special code in GNAT to support Interix,
since this is pretty much a vanilla Unix port.

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<Sorry.  I did not mean to imply that Interix only provides POSIX
libraries, however isn't that what we are talking about here?  U/WIN
certainly offers more than just a 'libc.a'.

For a user of U/WIN, U/WIN looks pretty much like any other Unix system.
>>

But Interix *IS* unix, it is simply a port of standard Unix code with the
low level interfaces of the kernel replaced by calls to the NT kernel.

I really am amazed at any attempt to equate U/WIN and Interix, I would
be surprised if anyone who had used and worked with interix would regard
it as anything other than a normal port of Unix. We are not just talking
library interfaces here, but the whole deal, tools, shells, etc, and
these are not just simulations of the Unix tools and shells, they ARE
the standard code, ported just as one would do the port for any other
Unix port.

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<I don't understand your analogy.  Are you implying that you have to buy
Tru64 before you buy OpenVMS?
>>

No, I am saying that if Compaq suddenly decided that you DID have to buy
Tru64 before you bought OpenVMS, this would NOT change the fact that
OpenVMS is an operating system.

And that seems to be the argument here, the argument is that since you
have to buy NT to run Interix, therefore Interix is not an operating
system. But that's just a marketing choice that Microsoft makes (basically
they assume, no doubt rightly, that no one would run Interix if they did
not also want to run Win32).

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<However, Interix is not normally distributed with the NT kernel.  So
it doesn't matter whether you consider the kernel to be the OS, or
Interix to be the OS, because you don't get both of them together than
you can't link a GPLed program with them and distribute it.
>>

To emphasize this further. OpenVMS is not normally distributed with
Tru64, but this does not mean that OpenVMS is therefore somehow in
the same category as third party software not covered by the exception.

The exception clause is with respect to an operating system, it is talking
about things athat are normally distributed with the operating system.

Interix *IS* an operating system, so the issue of the exception clause is
with respect to what components are normally distributed with Interix.

Re: Removal of support for GCC hosted on UWIN

[Christopher Faylor]

On Wed, Jan 10, 2001 at 04:32:40PM -0500, dewar@gnat.com wrote:
><<However, Interix is not normally distributed with the NT kernel.  So
>it doesn't matter whether you consider the kernel to be the OS, or
>Interix to be the OS, because you don't get both of them together than
>you can't link a GPLed program with them and distribute it.
>>>
>
>To emphasize this further. OpenVMS is not normally distributed with
>Tru64, but this does not mean that OpenVMS is therefore somehow in
>the same category as third party software not covered by the exception.

I don't understand your analogy.  Are you implying that you have to buy
Tru64 before you buy OpenVMS?

cgf

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<However, Interix is not normally distributed with the NT kernel.  So
it doesn't matter whether you consider the kernel to be the OS, or
Interix to be the OS, because you don't get both of them together than
you can't link a GPLed program with them and distribute it.
>>

Interix is an operating system, and it is normally distributed with itself
when you buy the Interix operating system. It is not distributed with NT,
because that is a quite different operating system. They happen to share
the same micro-kernel that is all.

What on earth do you mean by "link a GPL'ed program with Interix" and
distribute it? This makes absolutely ZERO sense. Interix is an operating
system, you don't link things with an operating system.

Now there may be some components of the Interix operating system that
are "nromally distributed" with Interix, that are subject to the 
GPL exception clause, though for the most part stuff is bound dynamically
anyway.

I really think people should buy and use Interix before they make
pronouncements. Trying to differentiate between interix and other
implementations of Unix seems quite bizarre to me.

Re: Removal of support for GCC hosted on UWIN

[dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]

<<Hopefully, I'm not confused about what people mean by NT since I have to
understand it fairly well to do my job.  IMO, Interix is an add-on to
the Windows NT operating system which provides full POSIX support.  It
is a proprietary package relying on Windows NT internals to do its job.
It certainly is a subsystem but it is also an additional package provided
by Microsoft in addition to Windows NT.
>>

Full POSIX support is a very strange way of defining this. It is simploy
a full Unix system, with all the normal Unix features. FOr a user of
Interix, NT+Interix looks pretty much like any other Unix system.

The technical structure, once again, is that NT is a microkernel system
with subsystems.

Technically there is no difference at all between

NT Kernel + Win32 => provides what people normally think of as the NT
operating system

NT Kernel + Interix => Provides an implementation of Unix

The two subsystems can of course be run together.

It is a marketing decision of Microsoft that the only way you can buy
the microkernel is to get the Win32 subsystem as well, so yes, in
marketing terms it is an add on.

<<I've never purchased Interix from Microsoft, so maybe I'm wrong, but I
don't believe that Microsoft markets this POSIX library as anything but
an add-on to Windows NT.  Here's the marketing blurb:
>>

Well we have worked extensively with Interix from the early non-Microsoft
days. As far as we are concerned it is just one more Unix system for which
we provide GNAT support. To think of Interix as a "POSIX library" is really
quite misleading, that is unless you think of SOlaris as nothing more than
a POSIX library :-)

Note that Win32 programs cannot somehow use Interix to provide POSIX
facilities, that's a compeltely wrong view of the strucure. The two
subsystems are quite separated.

Historically (and perhaps this accounts for part of the confusion),
Microsoft built at POSIX subsystem with minimal capabilities (about
all it could do was run the POSIX tests), to convince the DoD that
NT was an open system supporting POSIX (amazingly they got away
with this rather deceptive^H^H^H^H^H^H^H^H^Hpeculiar approach).

Softway Systems then acquired the code for this subsystem and used
it as the starting point to develop a complete implementation of
Unix as an NT subsystem. This version of Unix is quite complete
(it was one of the easier Unices from the point of view of porting
GNAT). Microsoft then later acquired Softway.

I think if you *had* "purchased Interix from Microsoft", you would have
a clearer view. I cannot imagine anyone familiar with Interix describing
it as anything else than a (fairly conventional) implementation of the
Unix operating system.

<<"Microsoft® Interix 2.2 is the easiest way for customers to take
advantage of their previous investments in UNIX-based legacy
applications as they move to the Windows® operating system.  Interix
provides a powerful, high-performance environment in which to easily run
UNIX applications and scripts on the Window NT® and Windows 2000
operating systems, enabling customers to take advantage of the many
benefits of the Windows platform while still maintaining their
UNIX-based legacy applications."
>>

I quite understand how reading this blurb may confuse you. Nothing it says
is actually *wrong*, but it is highly (perhaps deliberately) misleading
people reading it into thinking that this is some compatibility library
for Unix applications, and you certainly can be excused for not realizing
that what Microsoft is talking about is a complete Unix implementation
that is quite separate from the Win32 world.

It is posible to write hybrid applications in which you have parts running
under Win32, and parts under Interix, communicating through sockets, but
you might as well be operating on separate machines as far as the level
of communication goes. Indeed one way to build such hybrid applications
in GNAT is to built the system as a distributed system, using the
distribution features built into Ada 95, where it just happens that the
two partitions are on the same physical machine.

Re: Removal of support for GCC hosted on UWIN

[Chris Faylor]

On Wed, Jan 10, 2001 at 03:13:25PM -0500, dewar@gnat.com wrote:
><<Hopefully, I'm not confused about what people mean by NT since I have to
>understand it fairly well to do my job.  IMO, Interix is an add-on to
>the Windows NT operating system which provides full POSIX support.  It
>is a proprietary package relying on Windows NT internals to do its job.
>It certainly is a subsystem but it is also an additional package provided
>by Microsoft in addition to Windows NT.
>>>
>
>Full POSIX support is a very strange way of defining this. It is simploy
>a full Unix system, with all the normal Unix features. FOr a user of
>Interix, NT+Interix looks pretty much like any other Unix system.

Sorry.  I did not mean to imply that Interix only provides POSIX
libraries, however isn't that what we are talking about here?  U/WIN
certainly offers more than just a 'libc.a'.

For a user of U/WIN, U/WIN looks pretty much like any other Unix system.

FYI.

>The technical structure, once again, is that NT is a microkernel system
>with subsystems.
>
>Technically there is no difference at all between
>
>NT Kernel + Win32 => provides what people normally think of as the NT
>operating system
>
>NT Kernel + Interix => Provides an implementation of Unix
>
>The two subsystems can of course be run together.
>
>It is a marketing decision of Microsoft that the only way you can buy
>the microkernel is to get the Win32 subsystem as well, so yes, in
>marketing terms it is an add on.

What other terms are there?  If the only way to get the product is to
purchase a complete NT system and there is no way to purchase just NT
Kernel + Interix, then Interix is an add-on.

You want to avoid considering it to be add-on because it uses NT kernel
calls and bypasses the Win32 layer.  However, Interix is not sold as an
operating system.  I doubt that anyone is purchasing Interix just so
they can have UNIX running on their PC.  It is probably, in fact, always
purchased as an add-on to Windows which provides UNIX functionality.

><<I've never purchased Interix from Microsoft, so maybe I'm wrong, but I
>don't believe that Microsoft markets this POSIX library as anything but
>an add-on to Windows NT.  Here's the marketing blurb:
>>>
>
>Well we have worked extensively with Interix from the early non-Microsoft
>days. As far as we are concerned it is just one more Unix system for which
>we provide GNAT support. To think of Interix as a "POSIX library" is really
>quite misleading, that is unless you think of SOlaris as nothing more than
>a POSIX library :-)
>
>Note that Win32 programs cannot somehow use Interix to provide POSIX
>facilities, that's a compeltely wrong view of the strucure. The two
>subsystems are quite separated.

Again, since we were (I thought) discussing POSIX libraries, that is
what I was talking about.

>Historically (and perhaps this accounts for part of the confusion),
>Microsoft built at POSIX subsystem with minimal capabilities (about
>all it could do was run the POSIX tests), to convince the DoD that
>NT was an open system supporting POSIX (amazingly they got away
>with this rather deceptive^H^H^H^H^H^H^H^H^Hpeculiar approach).
>
>Softway Systems then acquired the code for this subsystem and used
>it as the starting point to develop a complete implementation of
>Unix as an NT subsystem. This version of Unix is quite complete
>(it was one of the easier Unices from the point of view of porting
>GNAT). Microsoft then later acquired Softway.
>
>I think if you *had* "purchased Interix from Microsoft", you would have
>a clearer view. I cannot imagine anyone familiar with Interix describing
>it as anything else than a (fairly conventional) implementation of the
>Unix operating system.

Actually, I purchased Interix from Softway prior to its acquisition by
Microsoft.

><<"Microsoft?  Interix 2.2 is the easiest way for customers to take
>advantage of their previous investments in UNIX-based legacy
>applications as they move to the Windows?  operating system.  Interix
>provides a powerful, high-performance environment in which to easily
>run UNIX applications and scripts on the Window NT?  and Windows 2000
>operating systems, enabling customers to take advantage of the many
>benefits of the Windows platform while still maintaining their
>UNIX-based legacy applications."
>>>
>
>I quite understand how reading this blurb may confuse you.  Nothing it
>says is actually *wrong*, but it is highly (perhaps deliberately)
>misleading people reading it into thinking that this is some
>compatibility library for Unix applications, and you certainly can be
>excused for not realizing that what Microsoft is talking about is a
>complete Unix implementation that is quite separate from the Win32
>world.

I understand very well how Interix operates, I know what a subsystem on
NT is, and I'm familiar with a few of the NT kernel calls that allow
Interix to implement UNIX so well.  In fact, I looked into using some of
them for Cygwin to provide functionality for fork().

So, you can stop educating me now.

>It is posible to write hybrid applications in which you have parts running
>under Win32, and parts under Interix, communicating through sockets, but
>you might as well be operating on separate machines as far as the level
>of communication goes. Indeed one way to build such hybrid applications
>in GNAT is to built the system as a distributed system, using the
>distribution features built into Ada 95, where it just happens that the
>two partitions are on the same physical machine.

Perhaps the implementation details of the way that Interix operates and
the fact that it is furnished by the vendor of the OS is sufficient to
exempt it from the GPL or from dropping Interix support from gcc.  I may
be wrong but I think that there is more than just a technical issue at
issue here.

I was wrong when I mentioned in a previous message that Interix used a
"slightly different" method from U/WIN.  Interix uses a completely
different method for accomplishing what it does.

Whether the isolation between Interix and Win32 is sufficient to make
the GPL a non-issue is obviously not for me to decide.

Since the GPL is as much a political document as a legal/technical one,
I wanted to raise the issues of how this package is marketed and
distributed by Microsoft in case that makes a difference in deciding
whether support for Interix should be continued.

cgf

Re: Removal of support for GCC hosted on UWIN

[dewar]

by the way, just so people know, GNAT is standardly targetted to Interix,
it is one of many ports supported by GNAT.

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<Interix is a trickier case: it is owned by the OS vendor and is being
marketed as "a native subsystem to Windows".  I don't know the answer,
but there are issues that distinguish it from U/WIN that may matter.
But RMS is going to look at it, I think.
>>

It *is* a native subsystem, this is not just marketing!

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<Ditto Interix, IMO.
>>

I strongly disagree, Interix is entirely equivalent to Win32 from a logical
point of view, it is one of the alternative subsystems offered for use
with the NT kernel. When using NT, the operating system consists of
the kernel + a subsystem of your choice. Microsoft offers two possible
subsystems, Win32, and Interix. The combination of the NT kernel and
Interix provides a typical Unix like operating system. In no sense
is Interix a separate unit operating on top of Win32.

Part of the confusion here is that when people say NT, they usually
mean the combination of the NT kernel + the Win32 subsystem. If this
is your meaning when you use the term NT, then Interix is NOT a library
that runs under NT, it is an operating system in all the normal uses
of the term.

Re: Removal of support for GCC hosted on UWIN

[Chris Faylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]

On Wed, Jan 10, 2001 at 10:43:19AM -0500, dewar@gnat.com wrote:
><<Ditto Interix, IMO.
>>>
>
>I strongly disagree, Interix is entirely equivalent to Win32 from a logical
>point of view, it is one of the alternative subsystems offered for use
>with the NT kernel. When using NT, the operating system consists of
>the kernel + a subsystem of your choice. Microsoft offers two possible
>subsystems, Win32, and Interix. The combination of the NT kernel and
>Interix provides a typical Unix like operating system. In no sense
>is Interix a separate unit operating on top of Win32.
>
>Part of the confusion here is that when people say NT, they usually
>mean the combination of the NT kernel + the Win32 subsystem. If this
>is your meaning when you use the term NT, then Interix is NOT a library
>that runs under NT, it is an operating system in all the normal uses
>of the term.

Hopefully, I'm not confused about what people mean by NT since I have to
understand it fairly well to do my job.  IMO, Interix is an add-on to
the Windows NT operating system which provides full POSIX support.  It
is a proprietary package relying on Windows NT internals to do its job.
It certainly is a subsystem but it is also an additional package provided
by Microsoft in addition to Windows NT.

I guess the fact that the "OS supplier" itself is now providing Interix
as an add-on might be a mitigating factor.  However, if Interix was not
supplied by Microsoft, there would be no doubt, IMO, that this was a
proprietary package.

I've never purchased Interix from Microsoft, so maybe I'm wrong, but I
don't believe that Microsoft markets this POSIX library as anything but
an add-on to Windows NT.  Here's the marketing blurb:

"Microsoft® Interix 2.2 is the easiest way for customers to take
advantage of their previous investments in UNIX-based legacy
applications as they move to the Windows® operating system.  Interix
provides a powerful, high-performance environment in which to easily run
UNIX applications and scripts on the Window NT® and Windows 2000
operating systems, enabling customers to take advantage of the many
benefits of the Windows platform while still maintaining their
UNIX-based legacy applications."

But, in any event, I don't really have that strong an opinion on the
matter.  Donn Terry from Interix has contributed code to gcc/bfd (much
of it actually helps Cygwin), so, at the very least, Interix has given
something back to the community.  I'm not aware of any such activity by
whomever owns U/WIN these days.

cgf

Re: Removal of support for GCC hosted on UWIN

[Geoff Keating]

dewar@gnat.com writes:

> <<Ditto Interix, IMO.
> >>
> 
> I strongly disagree, Interix is entirely equivalent to Win32 from a logical
> point of view, it is one of the alternative subsystems offered for use
> with the NT kernel. When using NT, the operating system consists of
> the kernel + a subsystem of your choice. Microsoft offers two possible
> subsystems, Win32, and Interix. The combination of the NT kernel and
> Interix provides a typical Unix like operating system. In no sense
> is Interix a separate unit operating on top of Win32.

However, Interix is not normally distributed with the NT kernel.  So
it doesn't matter whether you consider the kernel to be the OS, or
Interix to be the OS, because you don't get both of them together than
you can't link a GPLed program with them and distribute it.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<>Ironically, we're pushing the UWIN users back to MSVC as the only
>viable compiler.
>>

I must say, I miss the point here, I do not see any irony here ...

Re: Removal of support for GCC hosted on UWIN

[dewar]

I cannot see any convincing argument that could be made in court or
anywhere else that would permit U/Win to be regarded as something that
meets the exception clause of the GPL. It is quite clear that this
software is *not* "normally distributed ..."

Re: Removal of support for GCC hosted on UWIN

[Christopher Faylor]

On Tue, Jan 09, 2001 at 05:00:44PM -0500, dewar@gnat.com wrote:
>I cannot see any convincing argument that could be made in court or
>anywhere else that would permit U/Win to be regarded as something that
>meets the exception clause of the GPL. It is quite clear that this
>software is *not* "normally distributed ..."

Ditto Interix, IMO.

cgf

Re: Removal of support for GCC hosted on UWIN

[Joe Buck]

> On Tue, Jan 09, 2001 at 05:00:44PM -0500, dewar@gnat.com wrote:
> >I cannot see any convincing argument that could be made in court or
> >anywhere else that would permit U/Win to be regarded as something that
> >meets the exception clause of the GPL. It is quite clear that this
> >software is *not* "normally distributed ..."
> 
> Ditto Interix, IMO.

Interix is a trickier case: it is owned by the OS vendor and is being
marketed as "a native subsystem to Windows".  I don't know the answer,
but there are issues that distinguish it from U/WIN that may matter.
But RMS is going to look at it, I think.

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<Doesn't x86/alpha Interix support also fall under the same cloud then? It
is also an unbundled product, albeit now owned by Microsoft the OS vendor,
but still not part of the base OS.
>>

That's confused, Interix has exactly the same status as Win32, it is a
subsystem of NT. You cannot use the NT kernel directly (for one thing, its
interfaces are not documented -- it is probably the only kernel in the world
which is not only proprietary, but its interfaces are considered proprietary
and secret -- and the Navy declares it to be an "open system" :-)

So in practice using NT means using NT + one of the subsystems, and the
combination of the two corresponds to a normal operating system.

So if it is OK to call Win32 an OS (and people usually mean NT kernel + Win 32
subsystem when they say NT), then it is equally right to call the NT kernel
+ Interix an OS).

Re: Removal of support for GCC hosted on UWIN

[Axel Kittenberger]

Okay, regarding linking to 'non-free' libraries for the copyright holder,

I've digged up my mail archive, here is the add
on:
---------------------------------------------------------------------------
    ...usual gnu header....

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
USA

    As a special exception, <name of copyright holder> gives permission to
    link this program with <FOO>, and distribute the resulting executable,
    without including the source code for <FOO> in the source
distribution.
---------------------------------------------------------------------------
<FOO> would be the official name of the specific software package that
your
program must link against to work properly.  You can include multiple
paragraphs like the last one if there are additional programs.

((( In my case it was sun's hotspot VM, however during development I
discovered it's better to dynamically load it either way ( withLoadLibrary()),
which is neither case a GPL violation as far I understood it, since it's not
linked with it. However this of non-importance here :o) )))


-- 
Sent through GMX FreeMail - http://www.gmx.net

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<So if one considers UWIN an operating system (as the phase
"hosted on UWIN" implies) why the prohibition?
What is it about UWIN that is different from SunOS or HPUX - or come
to that Mingw32 where we don't have the source to MS's C runtime.

(Being devils advocate mainly - just to try and under stand
 what GCC folk understand by GPL.)
>>

The GCC folk understand nothing more and nothing less than what the
license says. Now as to the *intepretation* of that license, i.e. 
exactly what the exception means, that's subject to discussion, and
since there is no case law here, no one can speak with absolute
legal authority. As with any license agreement, ultimately the terms
have to be interpreted by a judge or jury :-)

Re: Removal of support for GCC hosted on UWIN

[dewar]

>Of what I understand of GPL, it's ok to link a GPL program with ANY
>library.  If that would be true, you could not link a GPL program with
>any commercial toolkit and there is clearly many such programs around!

This is incorrect, a program aggregated by linking a GPL program with
another library which is NOT part of the operating environment cannot
be distributed under the terms of the GPL. That's fundamental and it
is actually a little surprising to read the above paragraph. I trust
no one is actually operating under such a serious misaprehension. If
they are, sounds like some copyright violation is taking place!

Re: Removal of support for GCC hosted on UWIN

[Nick Ing-Simmons]

<dewar@gnat.com> writes:
>>Of what I understand of GPL, it's ok to link a GPL program with ANY
>>library.  If that would be true, you could not link a GPL program with
>>any commercial toolkit and there is clearly many such programs around!
>
>This is incorrect, a program aggregated by linking a GPL program with
>another library which is NOT part of the operating environment cannot

You last quote said "operating system" - which, while vague, most programmers
would have a reasonable idea what is meant.

But _anything_ could be considered part of the "operating environment" ...

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<So how does a binary that links (say) HPUX's libc.sl, or Sun's libc.so
get allowed?
>>

Well I guess the answer is RTFL (L = license). There is a clear
distinction made in the last paragraph but one of section 3 that
obviously applies to the examples you cite here:

------
However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

Re: Removal of support for GCC hosted on UWIN

[Nick Ing-Simmons]

<dewar@gnat.com> writes:
><<So how does a binary that links (say) HPUX's libc.sl, or Sun's libc.so
>get allowed?
>>>
>
>Well I guess the answer is RTFL (L = license). There is a clear
>distinction made in the last paragraph but one of section 3 that
>obviously applies to the examples you cite here:
>
>------
>However, as a
>special exception, the source code distributed need not include
>anything that is normally distributed (in either source or binary
>form) with the major components (compiler, kernel, and so on) of the
>operating system on which the executable runs, unless that component
>itself accompanies the executable.

So if one considers UWIN an operating system (as the phase
"hosted on UWIN" implies) why the prohibition?
What is it about UWIN that is different from SunOS or HPUX - or come 
to that Mingw32 where we don't have the source to MS's C runtime.

(Being devils advocate mainly - just to try and under stand
 what GCC folk understand by GPL.)


-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: Removal of support for GCC hosted on UWIN

[dewar]

<<Note that GCC is merely a special case: it is a violation of the GPL
to link *any* GPL'd program with the U/WIN support library.
>>

We need to clarify a bit, anyone can do this for themselves, it is
*distributing* the resulting program that is the potential violation
of the GPL. The act of linking is never of itself a violation of the
license.

RE: Removal of support for GCC hosted on UWIN

[David Korn]

>-----Original Message-----
>From: Alexandre Oliva [ mailto:aoliva@redhat.com ]
>Sent: 09 January 2001 09:14
>
>On Jan  9, 2001, Mark Mitchell <mark@codesourcery.com> wrote:
>
>> Note that GCC is merely a special case: it is a violation of the GPL
>> to link *any* GPL'd program with the U/WIN support library.
>
>I don't even know what U/WIN is but, AFAIK, the GNU GPL only covers
>the *distribution* of GNU GPLed programs or libraries.  Linking with a
>proprietary library is legal, as long as you don't redistribute the
>result of the linking.
>
>I understand the removing support from U/WIN is a form of making it
>harder for someone to violate the GNU GPL, but I thought I'd point out
>that anyone is free to take the patch you're about to remove, install
>it in their own GCC source tree and build GCC for their own use.
>Right?

  Wouldn't it be possible to just disable statically linking the shared lib?
Wouldn't that make it impossible to violate the GPL but allow the target
support to be retained ?  [Please note that asking this question alas does
not amount to an offer to do the work - sorry!]

     DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community." 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Removal of support for GCC hosted on UWIN

[Alexandre Oliva]

On Jan  9, 2001, David Korn <dkorn@pixelpower.com> wrote:

>   Wouldn't it be possible to just disable statically linking the shared lib?

The GNU GPL doesn't make any difference between linking with a shared
or static library.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Removal of support for GCC hosted on UWIN

[Nick Ing-Simmons]

Alexandre Oliva <aoliva@redhat.com> writes:
>On Jan  9, 2001, David Korn <dkorn@pixelpower.com> wrote:
>
>>   Wouldn't it be possible to just disable statically linking the shared lib?
>
>The GNU GPL doesn't make any difference between linking with a shared
>or static library.

So how does a binary that links (say) HPUX's libc.sl, or Sun's libc.so 
get allowed?

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: Removal of support for GCC hosted on UWIN

[Alexandre Oliva]

On Jan  9, 2001, Nick Ing-Simmons <nik@tiuk.ti.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Jan  9, 2001, David Korn <dkorn@pixelpower.com> wrote:
>> 
>>> Wouldn't it be possible to just disable statically linking the shared lib?
>> 
>> The GNU GPL doesn't make any difference between linking with a shared
>> or static library.

> So how does a binary that links (say) HPUX's libc.sl, or Sun's libc.so 
> get allowed?

There's an exception in the GNU GPL that allows linking with standard
components of the operating system.  Read the license for the gory
details.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Removal of support for GCC hosted on UWIN

[Mark Mitchell]

We've learned that the usage of GCC on U/WIN involves a violation of
the GNU GPL, linking GCC with a non-free third-party support library;
therefore, we have removed the support for such usage.

Note that GCC is merely a special case: it is a violation of the GPL
to link *any* GPL'd program with the U/WIN support library.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Removal of support for GCC hosted on UWIN

[Alexandre Oliva]

On Jan  9, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> Note that GCC is merely a special case: it is a violation of the GPL
> to link *any* GPL'd program with the U/WIN support library.

I don't even know what U/WIN is but, AFAIK, the GNU GPL only covers
the *distribution* of GNU GPLed programs or libraries.  Linking with a
proprietary library is legal, as long as you don't redistribute the
result of the linking.

I understand the removing support from U/WIN is a form of making it
harder for someone to violate the GNU GPL, but I thought I'd point out
that anyone is free to take the patch you're about to remove, install
it in their own GCC source tree and build GCC for their own use.
Right?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Removal of support for GCC hosted on UWIN

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> On Jan 9, 2001, Mark Mitchell <mark@codesourcery.com>
    Alexandre> wrote:

    >> Note that GCC is merely a special case: it is a violation of
    >> the GPL to link *any* GPL'd program with the U/WIN support
    >> library.

    Alexandre> I don't even know what U/WIN is but, AFAIK, the GNU GPL
    Alexandre> only covers the *distribution* of GNU GPLed programs or
    Alexandre> libraries.  Linking with a proprietary library is
    Alexandre> legal, as long as you don't redistribute the result of
    Alexandre> the linking.

I believe that to be correct.

    Alexandre> I understand the removing support from U/WIN is a form
    Alexandre> of making it harder for someone to violate the GNU GPL,
    Alexandre> but I thought I'd point out that anyone is free to take
    Alexandre> the patch you're about to remove, install it in their
    Alexandre> own GCC source tree and build GCC for their own use.
    Alexandre> Right?

I believe that is correct as well.

It's difficult to provide a brief summary of any legal document
(including the GPL) that is simultaneously completely comprehensive.
Thank you for pointing out this issue.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Removal of support for GCC hosted on UWIN

[Andi Kleen]

On Tue, Jan 09, 2001 at 09:42:41AM +0100, Mark Mitchell wrote:
> 
> We've learned that the usage of GCC on U/WIN involves a violation of
> the GNU GPL, linking GCC with a non-free third-party support library;
> therefore, we have removed the support for such usage.
> 
> Note that GCC is merely a special case: it is a violation of the GPL
> to link *any* GPL'd program with the U/WIN support library.

Why? On a U/WIN host the Uwin library is a system library (because U/WIN is the
system), and the GPL allows linking with proprietary system libraries.


-Andi

Re: Removal of support for GCC hosted on UWIN

[Mark Mitchell]

>>>>> "Andi" == Andi Kleen <ak@muc.de> writes:

    >> Note that GCC is merely a special case: it is a violation of
    >> the GPL to link *any* GPL'd program with the U/WIN support
    >> library.

    Andi> Why? On a U/WIN host the Uwin library is a system library
    Andi> (because U/WIN is the system), and the GPL allows linking
    Andi> with proprietary system libraries.

I didn't make this decision -- I'm merely representing the FSF
in this regard, and doing my job as a GCC maintainer to carry out the
FSF's instructions.  So, it's possible that what I say will not
precisely represent the FSF.  For more details, you should contact the
FSF directly.

However, I believe the FSF does not agree with the core assumption in
your statement; namely, that U/WIN is an operating system.  Instead, I
think it is viewed simply as a program/library/set of programs that
run on Windows NT (which *is* an operating system).

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Removal of support for GCC hosted on UWIN

[Mumit Khan]

On Tue, 9 Jan 2001, Mark Mitchell wrote:

> However, I believe the FSF does not agree with the core assumption in
> your statement; namely, that U/WIN is an operating system.  Instead, I
> think it is viewed simply as a program/library/set of programs that
> run on Windows NT (which *is* an operating system).

Mark,

As someone who worked on x86 UWIN support, I'm obviously interested
in this issue. As I understand from the messages so far, it is in violation
of the GPL to *distribute* UWIN linked binaries; but is it a violation if
a user takes the gcc source distribution and then builds it on a system
that has UWIN installed?

Doesn't x86/alpha Interix support also fall under the same cloud then? It 
is also an unbundled product, albeit now owned by Microsoft the OS vendor, 
but still not part of the base OS.

Regards,
Mumit

Re: Removal of support for GCC hosted on UWIN

[Mark Mitchell]

>>>>> "Mumit" == Mumit Khan <khan@NanoTech.Wisc.EDU> writes:

    Mumit> As someone who worked on x86 UWIN support, I'm obviously
    Mumit> interested in this issue. As I understand from the messages
    Mumit> so far, it is in violation of the GPL to *distribute* UWIN
    Mumit> linked binaries; but is it a violation if a user takes the
    Mumit> gcc source distribution and then builds it on a system that
    Mumit> has UWIN installed?

I believe not.  As others have said, I believe that if every user
builds GCC by herself, then there is no violation.  I'm not sure what
happens in a corporate environment if IT builds GCC and puts it on a
server that others use, or emails it to people in remote offices.  All
of these questions are good -- but I'm not qualified to answer them.

As with all such questions, you should ask the FSF -- and an attorney.

    Mumit> Doesn't x86/alpha Interix support also fall under the same
    Mumit> cloud then?

I don't know enough of the details, but that sounds plausible.  

I just work here...

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Removal of support for GCC hosted on UWIN

[Christopher Faylor]

On Tue, Jan 09, 2001 at 10:54:04AM -0800, Mark Mitchell wrote:
>Mumit> Doesn't x86/alpha Interix support also fall under the same
>Mumit> cloud then?
>
>I don't know enough of the details, but that sounds plausible.

AFAIK, the two are exactly the same.  Interix uses a slightly different
mechanism but these are still proprietary libraries.

cgf

Re: Removal of support for GCC hosted on UWIN

[Jeffrey A Law]

 In message < Pine.HPP.3.96.1010109122930.6367G-100000@hp2.xraylith.wisc.edu >yo
u write:
  > On Tue, 9 Jan 2001, Mark Mitchell wrote:
  > 
  > > However, I believe the FSF does not agree with the core assumption in
  > > your statement; namely, that U/WIN is an operating system.  Instead, I
  > > think it is viewed simply as a program/library/set of programs that
  > > run on Windows NT (which *is* an operating system).
  > 
  > Mark,
  > 
  > As someone who worked on x86 UWIN support, I'm obviously interested
  > in this issue. As I understand from the messages so far, it is in violation
  > of the GPL to *distribute* UWIN linked binaries; but is it a violation if
  > a user takes the gcc source distribution and then builds it on a system
  > that has UWIN installed?
You should talk to RMS since UWIN host support was removed at his
request.

  > Doesn't x86/alpha Interix support also fall under the same cloud then? It 
  > is also an unbundled product, albeit now owned by Microsoft the OS vendor, 
  > but still not part of the base OS.
Possibly.  Again it's something you might want to discuss with RMS.

jeff

Re: Removal of support for GCC hosted on UWIN

[Joe Buck]

Mumit writes:

> As someone who worked on x86 UWIN support, I'm obviously interested
> in this issue. As I understand from the messages so far, it is in violation
> of the GPL to *distribute* UWIN linked binaries; but is it a violation if
> a user takes the gcc source distribution and then builds it on a system
> that has UWIN installed?

I don't believe that the user has committed any offense by doing this, but
s/he can't give the binary to others.  But the alternative, it seems,
would then be to put in big warnings to people building on UWIN about
legal restrictions.

> Doesn't x86/alpha Interix support also fall under the same cloud then? It 
> is also an unbundled product, albeit now owned by Microsoft the OS vendor, 
> but still not part of the base OS.

At the risk of sounding like Bill Clinton, it all depends on what you say
an OS is.  On platforms where the compiler and its support library is
unbundled, RMS's attitude has been to treat it as bundled for the purpose
of the GPL (so linking with the language support libraries is OK).  But
clearly it's a fuzzy line.

This thing is arguable; I suppose someone could try to take it to court
and get U/WIN+Windows ruled as being an O/S for the purposes of the
GPL. Anyway, as Mark said, we just work here, for legal matters like this
the FSF decides and we've agreed to go along.

But I guess we should ask RMS about Interix.

Re: Removal of support for GCC hosted on UWIN

[Joseph S. Myers]

On Tue, 9 Jan 2001, Mark Mitchell wrote:

> I didn't make this decision -- I'm merely representing the FSF
> in this regard, and doing my job as a GCC maintainer to carry out the
> FSF's instructions.

Could all such direct instructions the FSF gives concerning GCC please be
posted to the public GCC mailing lists verbatim or put on the web site
verbatim or both?  (That is, this instruction, and all past and future
instructions.)  Preferably, in future, could the FSF please make their
requests direct to the public GCC lists in the first instance?

I don't object to this particular request, but in general I think the
public mailing lists should be the place such requests (e.g., the past
removal of assignment forms from the website) are justified by the FSF and
discussed in the first instance rather than after action has been taken,
unless a pressing justification for secrecy (e.g. pending or ongoing legal
action) is made.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Removal of support for GCC hosted on UWIN

[Mark Mitchell]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

    Joseph> Could all such direct instructions the FSF gives
    Joseph> concerning GCC please be posted to the public GCC mailing
    Joseph> lists verbatim or put on the web site verbatim or both?

The first paragraph of the words I posted *were* the exact words I was
asked to post.  The second paragraph (bearing on other programs using
the GPL) was my own.

    Joseph> I don't object to this particular request, but in general
    Joseph> I think the public mailing lists should be the place such
    Joseph> requests (e.g., the past removal of assignment forms from
    Joseph> the website) are justified by the FSF and discussed in the
    Joseph> first instance rather than after action has been taken,
    Joseph> unless a pressing justification for secrecy (e.g. pending
    Joseph> or ongoing legal action) is made.

The FSF owns the rights to the code, and so the FSF can make decisions
like this without consulting anybody.  (Of course, the GPL itself
gives everyone certain rights with respect to the code that would be
hard for the FSF to revoke.)

There are arguments for and against greater openness.

In any case, you should make this motion to the FSF itself; there's
nothing we can do directly.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Removal of support for GCC hosted on UWIN

[Chris G. Demetriou]

[ i've cc'd RMS since you suggested that we ask the FSF about this and
he's probably the right person. ]

mark@codesourcery.com (Mark Mitchell) writes:
> The FSF owns the rights to the code, and so the FSF can make decisions
> like this without consulting anybody.  (Of course, the GPL itself
> gives everyone certain rights with respect to the code that would be
> hard for the FSF to revoke.)

The FSF can make decisions like this without consulting anybody,
certainly.  And the steering committee, as an instrument (to some
degree) of the FSF is responsible for carrying out the FSF's wishes.

I don't think anybody -- except U/WIN users and people who time and
effort into the U/WIN code -- is going to care overly much about the
fate of U/WIN support.  It's the process and reasoning for making the
decision to remove U/WIN support that's concerning.

GCC is a technical project, but it's been used for what amount to
political purposes in the past.  It's the perogative of the owner of
the source to decide what is to be included, and what is not, and if
that is done for political ends, so be it.

However, the developers who are contributing code to gcc have a right
to know what positions their code is being used as a 'lever' to
advocate.  Not a legal right, certainly (at least, I didn't see
anything in the assignment form that promised that 8-), but I'd say a
moral one.

Therefore, in my opinion, not telling contributors is unfair to them,
and, as far as I'm concerned, also casts doubt on the motives of the
SC and the FSF for demanding that the source be changed for no given
reason.


By the way, I don't see anything on the GCC mission statement that
says that when the FSF or RMS says "jump," the GCC project (as steered
by the steering committee) has to say "how high."  Certainly there's
some motivation for that, but if the demand is to make a change which
is not technically sound, there should, in my opinion, be pushback.
(I don't see how a change which, for no documented reason removes
support for a platform, to the detriment of that platform's users and
creating extra work for developers can be considered "sound."
Reasoning is needed.)

I do, on the other hand, see things like:

	* Supporting the goals of the GNU project, as defined by the FSF.

The way I read that, if changes are being made to support those goals,
both those goals and the reason for the changes should be enunciated.
Otherwise, you can get into the situation where the FSF has the
ability to effectively 'black-list' companies or groups, without the
public even having any real notion that it's happening.


I've not seen any justification for removing the U/WIN support here
other than the flawed (AFAICT) logic in the original message you sent
(since it discounted the notion of u/win users building their own
binaries which from commentary by others seems a reasonable
proposition) and the appeal to authority ("ask the FSF").

I can imagine a whole host of reasons why the FSF would make the
request, pretty much all of which are reasonable as long as they are
honest.

However, not providing a reason at all seems quite unreasonable.


The consequences of not providing justification in this case seem
relatively minor, but the precedent is a bit unsettling.  All it can
do is lead to distrust within, and fragmentation of, the user
community.



cgd
--
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD or my employer, just expressing my
own opinion.

Re: Removal of support for GCC hosted on UWIN

[Mark Mitchell]

>>>>> "Chris" == Chris G Demetriou <cgd@netbsd.org> writes:

    Chris> By the way, I don't see anything on the GCC mission
    Chris> statement that says that when the FSF or RMS says "jump,"
    Chris> the GCC project (as steered by the steering committee) has
    Chris> to say "how high."  

I'm not going to comment on the U/WIN particulars.  I'm not an expert
on U/WIN.

However, the GCC mission statement is not the operative document to
govern my behavior as a GCC co-maintainer.  That is a position granted
me by the FSF, and along with certain rights and privileges, it
carries definite moral responsibilities.  In particular, even were I
to disagree with an FSF decision, I would either honor that decision,
or resign my position.  That does not mean I do not occasionally
disagree with the FSF, or argue for alternative positions -- but, in
the end, I will either acquiesce or remove myself.

RMS asked the SC to remove this code.  So, I removed it.  It really is
that simple.  (FWIW, the original idea was to remove all U/WIN bits; I
suggested that we leave the U/WIN target bits, since GCC is already
used to build non-GPL'd programs in many situations.)

The mere fact that there may be uses of the removed code which do not
violate the GPL really has no bearing.  It's an FSF judgement call as
to whether or not to include that code.  The FSF chose not to do so.
That makes building a U/WIN hosted compiler more difficult -- but
reduces the chance that people will (perhaps accidentally!) violate
the GPL.

It also raises awareness of the FSF's position regarding U/WIN in
particular, and other similar environments in general, as evidence by
this discussion.  That is good; otherwise, people might believe that
that the FSF doesn't really care if you put a U/WIN hosted compiler on
an ftp site, for example.  Now, it is clear that the FSF does not want
people to do this, and believes that the GPL prohibits such an action.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Removal of support for GCC hosted on UWIN

[Mumit Khan]

On Tue, 9 Jan 2001, Mark Mitchell wrote:

> It also raises awareness of the FSF's position regarding U/WIN in
> particular, and other similar environments in general, as evidence by
> this discussion.  That is good; otherwise, people might believe that
> that the FSF doesn't really care if you put a U/WIN hosted compiler on
> an ftp site, for example.  Now, it is clear that the FSF does not want
> people to do this, and believes that the GPL prohibits such an action.

I need to remove all UWIN ports of gcc from my site (from egcs-1.0.x to 
2.95.2); while I'm doing that, I'd like to send an note to the many users 
who've depended on GCC being available on the platform and explain why 
we are doing this. I know there are quite a few sites mirroring my
distributions, and I'll send a note to the ones I know about.

Could I possibly get a note from FSF detailing the reason behind the
removal of UWIN? If not possible, I'll just gather up various messages
in the gcc list (eg., those from the various SC members), and compile
a note from that.

I assume that this also affects binutils and gdb ports and will remove
those as well as soon as I can.

Ironically, we're pushing the UWIN users back to MSVC as the only viable
compiler.

Regards,
Mumit

Cc: RMS

Re: Removal of support for GCC hosted on UWIN

[Joseph S. Myers]

On Tue, 9 Jan 2001, Mumit Khan wrote:

> I need to remove all UWIN ports of gcc from my site (from egcs-1.0.x to
> 2.95.2); while I'm doing that, I'd like to send an note to the many users

I presume UWIN host support will also be removed in 2.95.3?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Removal of support for GCC hosted on UWIN

[Christopher Faylor]

On Tue, Jan 09, 2001 at 11:11:26PM -0600, Mumit Khan wrote:
>Ironically, we're pushing the UWIN users back to MSVC as the only
>viable compiler.

Couldn't they use a mingw gcc compiler to accomplish their goals?
If MSVC works, then mingw should too.

cgf

Re: Removal of support for GCC hosted on UWIN

[Joe Buck]

Chris Demetriou writes:
> By the way, I don't see anything on the GCC mission statement that
> says that when the FSF or RMS says "jump," the GCC project (as steered
> by the steering committee) has to say "how high."  Certainly there's
> some motivation for that, but if the demand is to make a change which
> is not technically sound, there should, in my opinion, be pushback.

Let me assure you that there is pushback: on the steering committee list
there are occasionally rather vigorous arguments where SC members push
back, hard, against something RMS requests, and RMS is often persuaded
that the original request wasn't such a good idea.

But this is a legal matter, and the SC tends to defer to RMS much more
on such things unless we think he misunderstands the facts.

> I've not seen any justification for removing the U/WIN support here
> other than the flawed (AFAICT) logic in the original message you sent
> (since it discounted the notion of u/win users building their own
> binaries which from commentary by others seems a reasonable
> proposition) and the appeal to authority ("ask the FSF").

There was an error in the original statement that Mark posted, yes.  It is
legal to link GPL and proprietary code, it's just not legal to distribute
or modify the result.  Just the same, to leave it in the distribution is
just going to lead people to infringe out of ignorance.

To clarify: the policy is that we're not going to ship anything that
has the effect, when you type "make bootstrap", of creating an executable
that is illegal to distribute.  If there are other problematic cases,
then they may be withdrawn as well.  Understood?

Re: Removal of support for GCC hosted on UWIN

[Richard Stallman]

      It's the process and reasoning for making the
    decision to remove U/WIN support that's concerning.

I made this decision.  The reason for the decision is that we must not
distribute code that appears to endorse the legitimacy of an activity
that we are condemning as a violation of our license.

I stand by this decision, and I will act likewise again in the future
if another occasion arises.

This decision is not political, it is legal.  However, the GNU Project
does make decisions for political reasons.  It has a political goal at
its very center: the goal that *software should be free*.  The purpose
of a GNU program such as GCC is not simply to "be a good program", but
to contribute to this overall goal.

The distinction is subtle, and only rarely makes a practical
difference.  Most GCC decisions are made for technical reasons alone,
because only technical factors come into most decisions.  But
sometimes political factors control a decision.  It will happen.

The GNU Project does not ask contributors to GCC to make a political
pledge--contributors are welcome regardless of their political views.
The flip side is that since we cannot count on contributors to share
our political goals, we do not give them a say in political decisions.
You are welcome to join in the technical work if you do not share our
political goals, but we are very selective about who participates in
our political decisions.

Our political views are no secret--they are described at length in
http://www.gnu.org/philosophy/ .  If you are familiar with them, the
occasional political decision should not be surprising.

Re: Removal of support for GCC hosted on UWIN

[Joe Buck]

> Why? On a U/WIN host the Uwin library is a system library (because U/WIN is the
> system), and the GPL allows linking with proprietary system libraries.

A user of U/WIN would be puzzled at the concept "a U/WIN host".
Furthermore when a GPLed application is built for U/WIN, the result
is not "a U/WIN application"; it is a Windows application, and can
be used in the normal Windows environment and not just the U/WIN
environment (ksh).

U/WIN is marketed as a package that runs on Windows systems that brings
extra functionality to WIN32 applications.  I challenge anyone to find
anything on

http://www.research.att.com/sw/tools/uwin/

that implies in any way that U/WIN is an OS.

Re: Removal of support for GCC hosted on UWIN

[Alain Magloire]

> 
> 
> > Why? On a U/WIN host the Uwin library is a system library (because U/WIN is the
> > system), and the GPL allows linking with proprietary system libraries.
> 
> A user of U/WIN would be puzzled at the concept "a U/WIN host".
> Furthermore when a GPLed application is built for U/WIN, the result
> is not "a U/WIN application"; it is a Windows application, and can
> be used in the normal Windows environment and not just the U/WIN
> environment (ksh).
> 
> U/WIN is marketed as a package that runs on Windows systems that brings
> extra functionality to WIN32 applications.  I challenge anyone to find
> anything on
> 
> http://www.research.att.com/sw/tools/uwin/
> 
> that implies in any way that U/WIN is an OS.

Is not U/Win in the same category as CygWin ?  Or DJGPP for that matter ?


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!

Re: Removal of support for GCC hosted on UWIN

[Joe Buck]

> Is not U/Win in the same category as CygWin ?  Or DJGPP for that matter ?

With CygWin and DJGPP, the linked-to libraries are free software.  With
U/Win, the linked-to library is proprietary, but is not (to quote the GPL)
"normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on which
the executable runs ...".  That's the difference.

Re: Removal of support for GCC hosted on UWIN

[Laurynas Biveinis]

On Tue, Jan 09, 2001 at 03:56:08PM -0500, Alain Magloire wrote:
> Is not U/Win in the same category as CygWin ?  Or DJGPP for that matter ?

They are different - DJGPP-hosted programs are not linked
with any proprietorial library.

Laurynas

Removal of support for GCC hosted on UWIN

[Michael Widenius]

Hi!

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> We've learned that the usage of GCC on U/WIN involves a violation of
Mark> the GNU GPL, linking GCC with a non-free third-party support library;
Mark> therefore, we have removed the support for such usage.

Mark> Note that GCC is merely a special case: it is a violation of the GPL
Mark> to link *any* GPL'd program with the U/WIN support library.

Sorry, but shouldn't it be the other way around?

Of what I understand of GPL, it's ok to link a GPL program with ANY
library.  If that would be true, you could not link a GPL program with
any commercial toolkit and there is clearly many such programs around!

It's only when you do it the other way around the GPL comes into
affect;

If you have a commercial program and link with a GPL library, then
it's a violation of the GPL if the commercial program is not GPL.

I am very interested in your reasoning about this;  Any change you can
point me out to the information/person on which you base your
statement?

Regards,
Monty
MySQL Moderator

Re: Removal of support for GCC hosted on UWIN

[Alexandre Oliva]

On Jan  9, 2001, Michael Widenius <monty@mysql.com> wrote:

> Of what I understand of GPL, it's ok to link a GPL program with ANY
> library.  If that would be true, you could not link a GPL program with
> any commercial toolkit and there is clearly many such programs around!

The GNU GPL requires that, if any component of an application is
licensed under its terms, the application can only be distributed
under the terms of the GNU GPL, with an exception granted to
components that are part of the operating system.

It doesn't matter if it's a GPLed program being linked with a non-GPL
library, or a non-GPLed program being linked with a GPLed library.  If
they're linked together, you can only distribute the results under the
terms of the GNU GPL.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Removal of support for GCC hosted on UWIN

[Mark Mitchell]

>>>>> "Michael" == Michael Widenius <monty@mysql.com> writes:

    Michael> Sorry, but shouldn't it be the other way around?

The GPL does not contain any notion of "direction".  The distribution
of a program comprising GPL'd code linked with code that does not
satisfy certain properties laid out in the GPL is not permitted.

    Michael> I am very interested in your reasoning about this; Any
    Michael> change you can point me out to the information/person on
    Michael> which you base your statement?

Richard Stallman (rms@gnu.org) is the unquestioned expert on the GPL.
His voice definitely carries more weight than mine; in this case,
however, I was acting under his direct instructions.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Removal of support for GCC hosted on UWIN

[Jeffrey A Law]

  In message < 20010109101303B.mitchell@codesourcery.com >you write:
  >     Michael> I am very interested in your reasoning about this; Any
  >     Michael> change you can point me out to the information/person on
  >     Michael> which you base your statement?
  > 
  > Richard Stallman (rms@gnu.org) is the unquestioned expert on the GPL.
  > His voice definitely carries more weight than mine; in this case,
  > however, I was acting under his direct instructions.
Just to confirm, Mark is acting under RMS's direct instructions.

jeff