Re: Nobody in the world understands Gnu's 'ld'.

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

In gnu-win32 root@jacob.remcomp.fr writes:

>Since several months people here report that Cygnus's linker is flawed.
>I think that it is just plain that Cygnus doesn't have the
>know-how to repair it, since Steve Chamberlain, the guy that
>wrote most of it, hasn't posted anything here since ages and
>he was very active before.

Let's not get carried away here.  I understand the linker perfectly
well, and so do a number of other people.

It's true that Steve Chamberlain left Cygnus a while ago.

If you look at the ChangeLog files, you can see who has been working
on the linker and other parts of BFD.  You'll see that although Steve
wrote most of the original code several years ago, he hasn't been
heavily involved with BFD or the linker for quite some time.

>Just to give you an idea, ld is supposed to link an object file
>from sun's unix format with some code from windows 95 and with
>some code of hp Unix. Of course this is ridiculous and it will never
>work, but this is how 'ld' is designed: an incredible complexity
>that (to me) seems completely unwarranted.

It's true that it is rare for people to link together different object
file formats.  However, you have missed the actual reasons for the
complexity.

The first reason is that the linker is able to generate an object file
format which is different from the input file formats.  For example,
this permits the linker to directly generate S-record output without
requiring a convertor.  This may not be too useful for native
programmers, but it is useful for embedded systems programmers.

The second reason is that a single linker binary can serve as the
linker for different targets.  The Linux people use this, for example:
the binary binutils distribution for Linux is built to support all the
various Linux targets in a single binary.

>It has a full blown LANGUAGE
>(with lex+yacc parser/lexer!) that is supposed to recognize linker
>commands. Obviously nobody ever uses it, but to understand
>what the linker is doing you have to go through yet another layer
>of complexity.

In fact, many people use the linker script language.  I can't imagine
why you think that nobody uses it.  Moreover, this is hardly a unique
or even unusual feature of the GNU linker: most linkers have a
scripting language, and the one used by the GNU linker is based on the
one used by the SVR3 linker.

>Then you have the 'BFD' format, that is supposed to be an universal
>binary format designed by GNU that will abstract the binary format
>of all machines in the western world into ONE format. Obviously
>it doesn't work, but then you have not only to understand what
>binary format you have in windows (what is difficult enough) but
>you have to understand BFD too.

In fact, BFD works quite well.  I don't know why you think that it
doesn't work.

It's not quite correct to describe BFD as abtracting all binary
formats into one format.  What it actually does is provide a library
interface which may be used to examine and generate an object file in
any format.

Mind you, I'm not going to defend the way that BFD is written.  There
is definitely a very steep learning curve before being able to program
using BFD.  I've tried to clean up some of the more egregious
problems.  Unfortunately, the cost of rewriting BFD is high.

>And to crown this beatiful construction there is NO DOCUMENTATION
>whatsoever about anything I have told you in this message. I inferred
>this from reading THE C CODE!!!

I'd love to have some documentation if you care to write some and
contribute it.  This is, after all, free software.  It improves by
contributions.

>That is why this linker can't even recognize MSVC object code
>format and use the MSVC .LIBs. Because nobody in the world
>is able to modify it. Of course we do not need compatibility
>with SUN or HP Unix under Windows 95. We would need MSVC
>compatibility. But to do that we would have to find somebody
>that understands 'ld'...

Well, all you need to do is add support for the object code format to
BFD.  I'm sorry you think that is impossible.  In fact, BFD supports a
number of object file formats already, including a.out, COFF, ELF,
IEEE-695, XCOFF, SOM, etc.  Adding another one is really not all that
difficult if you know what you are doing.

I'm always willing to answer specific questions about BFD and the
linker.  I'm not willing to give a tutorial on how to program it,
because I simply don't have the time.

I suppose I should add that my personal interest in adding MSVC object
support is nil.  I do work at Cygnus, but I don't work on gnu-win32,
and I have no idea whether Cygnus has any plans to do anything in this
area.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Mr Taylor surely understands ld: a correction to my previous post

[root]

I sent earlier this morning a message stating that nobody understands ld.

This is surely not true for Mr Taylor.

I saw his comments when reading ld's code, and they were helpful.
I just let myself go, expressing (for the first time I think) this feeling of
frustration I got from my weeks studying that code.

There are some basic rules of software engineering that we somehow take for
granted. For instance, a .h file contains declarations, and a .c file contains
executable code. This is not the case with 'ld'. The file 'coff.h' contains
executable code that is included TWICE (yes, the same file) in the code of
'ld' with different #defines as input. This works because all the functions
in that file are declared static and accessed by several indirection tables. 

Problem is, most debuggers get confused with this... not to speak of the poor 
guy *reading* that code!

But it is the whole philosophy behind this that is flawed. 
Mr Taylor writes:

> ...the linker is able to generate an object file
> format which is different from the input file formats.  For example,
> this permits the linker to directly generate S-record output without
> requiring a convertor.

But WHY do we have to put the convertor and the linker in the SAME PROGRAM!!!
In my view of things, it would be much better to have an easy to understand
convertor to be used by systems programmers when they need S records, than
to overload the linker with YET ANOTHER LEVEL OF COMPLEXITY!!!

Besides, 99.9999% of the people that use 'ld' daily, are loading that code 
to produce S records FOR NOTHING. The linker takes more space and is more
difficult to maintain! 

MODULARITY is a thing that got lost in this 'ld' crazyness. Do a program to
do ONE THING and do that well. Do another program for another task. Do not
build program upon program in the same executable. You do not have a
razor inside your TV set in case you want to shave yourself when watching
TV!!!

The linker I wrote, went the opposite direction: It is FAST, and its size is
only 66K. It understands only ONE format: windows COFF object. It will crash
with any other object file. It doesn't produce S-records, but it does produce
a readable MAP FILE with the information of the offset of EACH LINE in your
object code. And it uses Microsoft's debug info format, so you can even
debug it... :-)

What are the consequences of building things like 'ld'?

They are better expressed by this (anonymous) comment
in the file 'reloc.c'

/* This relocation routine is used by some of the backend linkers.
   They do not construct asymbol or arelent structures, so there is no
   reason for them to use bfd_perform_relocation.  Also,               <<<<<
   bfd_perform_relocation is so hacked up it is easier to write a new  <<<<<
   function than to try to deal with it.                               <<<<<
*/

So, instead of dealing with 'bfd_perform_relocation', that should relocate
object code from one object format into another (!!), people write their own
routines again, since that function is beyond what a human mind can follow!


The fact remains, that ld is producing bad executables since a long time.
Sometimes. When the program gets big enough, or when somehow a new API call
is invoked. There were people that pointed that out 2-3 months ago. A program
stopped working when it reached a size threshold. I have seen no announcements
of any corrections.

I still remain convinced that only Steve can fix this. It is a pity that he
is gone. This means that this problem will remain as it is in the foreseeable
future.

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Ian Lance Taylor wrote:
> 
> Let's not get carried away here.  I understand the linker perfectly
> well, and so do a number of other people.
[...]
> In fact, BFD works quite well.

Yes, I agree.  Let's not get carried away.

However, let's not forget the point either: the GNU ld code
is poorly structured and poorly documented.

> Mind you, I'm not going to defend the way that BFD is written.
> [...] I've tried to clean up some of the more egregious
> problems.  Unfortunately, the cost of rewriting BFD is high.

Right.  So what is the solution?  Well, in the case of BFD, perhaps the
damage is already done -- the cost would have been a lot cheaper if it
was done right in the first place.  However, even now, Cygnus should
seriously consider spending the money to improve the quality of their
existing source code, because it may be a *good investment*.

Regardless of what happens with BFD, Cygnus ought to ensure that
whatever code they write is well documented and properly structured.
This will result in products that are easier to maintain, easier
to extend, and as a result in the long term the products will be better.

> I'd love to have some documentation if you care to write some and
> contribute it.  This is, after all, free software.  It improves by
> contributions.

Documentation should not be an after-thought.  If Cygnus thinks that
it can economize by not bothering with documentation or not bothering
to write properly structured code, then they are wrong -- it may result
in some short-term gains, but in the long run it will cost them a lot.
It is much more difficult (and expensive) for someone to come along
afterwards and write documentation than for the person doing the
original work to write the documentation properly in the first place.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Joel Dinolt]

Fergus Henderson wrote:

> Regardless of what happens with BFD, Cygnus ought to ensure that
> whatever code they write is well documented and properly structured.
> This will result in products that are easier to maintain, easier
> to extend, and as a result in the long term the products will be better.
<cut> 
I don't know if all this stuff about "Cygnus should do this, Cygnus
should do that..." is accurate...I thought GNU ld was part of the
standart GNU package, and that the ld with cyg-win32 was just a port
win32 port of the standard GNU ld. If this is the case, it's not
really Cygnus that should be "making sure it is well documented
and properly structured."  I would assume that the structure has been
an evolution over many years(like emacs or rcs or cvs) and has been
tinkered with by many people.  And as far as documentation, it might
be easiest to start at the GNU Home Page, since it is the cyg-win32 
ld is based on the standard GNU ld...of course, if the ld is 
a custom linker that cygnus wrote, it's another matter...but
free software is free software, and you have the source, as
cryptic as it may be.  Isn't 70% of programming getting frustrated
by having to read someone elses oddly structured code to figure out
what it does?  I could be speaking from a somewhat tainted perspective
here, as I'm a video game programmer doing a port, and I do windows
programming "for fun"....

Regards,
Joel Dinolt,
jdinolt@pacbell.net
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Mr Taylor surely understands ld: a correction to my previous post

[Fergus Henderson]

Jacob Navia wrote:
> 
> But it is the whole philosophy behind this that is flawed. 
> Mr Taylor writes:
> 
> > ...the linker is able to generate an object file
> > format which is different from the input file formats.  For example,
> > this permits the linker to directly generate S-record output without
> > requiring a convertor.
> 
> But WHY do we have to put the convertor and the linker in the SAME PROGRAM!!!

Here's one possible reason (there may be others).

Different object file formats formats have different sets of capabilities.
In general, conversion from one format to another format may not be
able to preserve all the information.  If the linker required all
inputs to have the same format, then you might have to use a lossy
conversion, and that might prevent successful linking.

One possible solution to this problem would be to invent a new object
file format whose capabilities were a superset of the capabilities of
all other object file formats.  Then, you could ensure that the
conversion to this object file format was non-lossy.  However, this
approach would be more complex than the BFD approach, not less complex.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Joel Dinolt wrote:
> 
> I thought GNU ld was part of the
> standart GNU package, and that the ld with cyg-win32 was just a port
> win32 port of the standard GNU ld. If this is the case, it's not
> really Cygnus that should be "making sure it is well documented
> and properly structured."

`ld' is part of the GNU binutils package, but Cygnus is (I believe)
the central maintainer of that package, just as Linus is the central
maintainer of the Linux kernel, Richard Kenner of the FSF is the
central maintainer of gcc, etc.

> I would assume that the structure has been
> an evolution over many years(like emacs or rcs or cvs) and has been
> tinkered with by many people.

Of course, but central maintainer who is responsible for merging in
all the different patches, issuing new releases, etc., should also
be responsible for maintaining the quality of the software.

> And as far as documentation, it might
> be easiest to start at the GNU Home Page, since it is the cyg-win32 
> ld is based on the standard GNU ld...

I was talking mainly about source documentation, not user documentation.
The user documentation for `ld' is actually quite good.

> but free software is free software, and you have the source, as
> cryptic as it may be.

Uh, no offence, but this sounds to me like a cop-out: are you
suggesting that because it is free software, it doesn't matter if the
quality is poor?

(Thankfully the people at Cygnus who have responded to this thread
_don't_ have that attitude.)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

   Date: Wed, 26 Mar 1997 15:13:49 +0100
   From: "Pedro A. Aranda Guti\irrez" <paag@tid.es>

   > > I'd love to have some documentation if you care to write some and
   > > contribute it.  This is, after all, free software.  It improves by
   > > contributions.

   Contributions sold afterwards by Cygnus. Forgive me, but if my
   work is going to produce benefits, they should be for me and not
   for someone else. I'm no DOn Quijote.

   Ergo => all this commercial licensing stuff of Cygnus has somehow
   rarified the atmosphere of FSF'ish software (that's at least my 
   feeling and my VERY personal opinion)

Don't get confused.  BFD, gas, ld, the binutils, are all under the GPL
and always have been.  Any contributions you or anybody chooses to
make will be made under the GPL, will require a copyright assignment
to the Free Software Foundation, and will be included in future
binutils net releases for anybody to use.

The commercial licensing stuff applies only to the gnu win32 library
itself, which is copyrighted by Cygnus.  It does not apply to the
binutils.

On another topic, to quote you: ``if my work is going to produce
benefits, they should be for me and not for someone else. I'm no DOn
Quijote.''  I'm sorry you feel that way.  If you are using the GNU
binutils, or any FSF software, or indeed the GPL version of gnu-win32
itself, then you are benefitting from the work of people who are
rather less selfish than you seem to be.

I've been working in free software for several years now, starting
some years before I joined Cygnus.  I would certainly say ``if my work
is going to produce benefits, they should be for me.''  I don't work
out of altruism.  However, I would never say that the benefits should
not be for someone else as well.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Pedro A. Aranda Gutiirrez]

Fergus Henderson wrote:
> 
> Ian Lance Taylor wrote:
> >
> > Let's not get carried away here.  I understand the linker perfectly
> > well, and so do a number of other people.
> [...]
> > In fact, BFD works quite well.
> [...]
> However, let's not forget the point either: the GNU ld code
> is poorly structured and poorly documented.

Yes, I'd not be as mild as Fergus. I went through the same sorrows as
Jacob Navia when trying to understand the DLLTOOL source. It was 
'somehow' documented and completely unstructured, ergo not
understandable.

> Regardless of what happens with BFD, Cygnus ought to ensure that
> whatever code they write is well documented and properly structured.

This is something I learnt years ago in University and even my
personal 'quick-hacks' follow this philosophy. It really pays off.

> > I'd love to have some documentation if you care to write some and
> > contribute it.  This is, after all, free software.  It improves by
> > contributions.

Contributions sold afterwards by Cygnus. Forgive me, but if my
work is going to produce benefits, they should be for me and not
for someone else. I'm no DOn Quijote.

Ergo => all this commercial licensing stuff of Cygnus has somehow
rarified the atmosphere of FSF'ish software (that's at least my 
feeling and my VERY personal opinion)

-- 

     +--------------------------------------------------------+
     |  ####   Pedro Andres Aranda Gutierrez                  |
     |  ####                                                  |
     |  ####   Telefonica I+D;  Network Interconnection Div.  |
     |  ====   C./ Emilio Vargas, 6    E-28043 Madrid, Spain  |
     |  ====   e-mail : paag@tid.es                           |
     |  ====   Tlf 34-1-337 47 02      FAX 34-1-337 45 02     |
     +--------------------------------------------------------+
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

   From: Fergus Henderson <fjh@cs.mu.oz.au>
   Date: Wed, 26 Mar 1997 18:17:04 +1100 (EST)

   > Mind you, I'm not going to defend the way that BFD is written.
   > [...] I've tried to clean up some of the more egregious
   > problems.  Unfortunately, the cost of rewriting BFD is high.

   Right.  So what is the solution?  Well, in the case of BFD, perhaps the
   damage is already done -- the cost would have been a lot cheaper if it
   was done right in the first place.  However, even now, Cygnus should
   seriously consider spending the money to improve the quality of their
   existing source code, because it may be a *good investment*.

   Regardless of what happens with BFD, Cygnus ought to ensure that
   whatever code they write is well documented and properly structured.
   This will result in products that are easier to maintain, easier
   to extend, and as a result in the long term the products will be better.

   > I'd love to have some documentation if you care to write some and
   > contribute it.  This is, after all, free software.  It improves by
   > contributions.

   Documentation should not be an after-thought.  If Cygnus thinks that
   it can economize by not bothering with documentation or not bothering
   to write properly structured code, then they are wrong -- it may result
   in some short-term gains, but in the long run it will cost them a lot.
   It is much more difficult (and expensive) for someone to come along
   afterwards and write documentation than for the person doing the
   original work to write the documentation properly in the first place.

I'll note that I agree with all of this.  In particular, we've
certainly discussed whether rewriting BFD is a good investment or
not.  There is no obvious right answer.

People may think that Cygnus is a large software company with hundreds
of programmers designing products.  This is not the case.  It was even
less the case when BFD and the linker were written.  At that time,
Cygnus was a handful of programmers working with free software and
struggling to succeed by meeting customer demands very quickly.  It's
easy to second guess the decisions made at that time.  In fact,
though, you weren't there, and neither was I.  Programming decisions
are not made in an academic environment.  They are made in the real
world, under the pressure of time and money.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Commercial Licensing

[David Essex]

Ian Lance Taylor <ian@cygnus.com> wrote:

>BFD, gas, ld, the binutils, are all under the GPL
>and always have been.  Any contributions you or anybody chooses to
>make will be made under the GPL, will require a copyright assignment
>to the Free Software Foundation, and will be included in future
>binutils net releases for anybody to use.
>
>The commercial licensing stuff applies only to the gnu win32 library
>itself, which is copyrighted by Cygnus.  It does not apply to the
>binutils.
Commercial licensing ?
The cygnus gnu-win32 web page says that this is free software.
If win32 library is part of gnu why do you need a commercial license ?
Could some one expand on this ? 

David


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

David Essex wrote:
> 
> Ian Lance Taylor <ian@cygnus.com> wrote:
> 
> >BFD, gas, ld, the binutils, are all under the GPL
> >and always have been.  Any contributions you or anybody chooses to
> >make will be made under the GPL, will require a copyright assignment
> >to the Free Software Foundation, and will be included in future
> >binutils net releases for anybody to use.
> >
> >The commercial licensing stuff applies only to the gnu win32 library
> >itself, which is copyrighted by Cygnus.  It does not apply to the
> >binutils.
> Commercial licensing ?
> The cygnus gnu-win32 web page says that this is free software.
> If win32 library is part of gnu why do you need a commercial license ?
> Could some one expand on this ?


In addition to the GPL, Cygnus offers cygwin.dll under a restricted
license to commercial clients who wish to use it without sharing their
own sources.  As the owner, Cygnus has every legal right to do this.
Whether it is consistent with the spirit of the GPL is another matter.
There was a long, heated debate on the mailing list after Cygnus
posted a press release announcing their intentions; no sense in
repeating it.

Note that many libraries, such as glibc, are released under the LGPL,
not the GPL, implicitly allowing commercial users to do what commercial
users of cygwin must pay Cygnus for a license to do.  Cygnus
intentionally used the GPL rather than the LGPL for just this reason.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Geoffrey Noer]

> The cygnus gnu-win32 web page says that this is free software.
> If win32 library is part of gnu why do you need a commercial license ?
> Could some one expand on this ? 

I just expanded the explanation for this a bit on the main WWW page.
Hopefully it will cut down on the amount of mail on this list that
pertains to this subject.

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Fergus Henderson]

Reed Kotler Consulting wrote:
> 
> I think I'll skip the gnu.misc.discuss. I need one more mailing
> list or newsgroup like I need a hole in my head.
...
> Has any of GPL ever been tested in court?

Many of us read the gnu-win32 mailing list for the technical issues,
and we need questions such as that one like we need the proverbial hole
in the head.

If you want to ask questions like that, fine, but please ask them
in the appropriate forum.  If you're too busy to ask them in the
appropriate forum, then don't ask them at all.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Robert W. Fuller]

Jim Balter wrote:
> 
> Reed Kotler Consulting wrote:
> 
> > I suppose thought that you could relink cygwin.dll adding those other
> > components and then you wouldnt be violating any rules.
> 
> libccrt0 has to live in the .exe, not the dll.  If Cygnus had published
> an interface specification for cygwin.dll then of course you could
> just say that you were following the spec if you provided your own
> version, but they haven't.  As I said, I don't know how copyright
> law applies to reverse engineering.

How copyright laws apply to reverse engineering is irrelevant if you
know how copyright laws apply to programming interfaces.  In fact, US
courts have set the precedent that copyright law does not apply to
programming interfaces, although it does apply to implementations. 
Therefore, if it pleased me to do so, I could write and distribute my
own substitute for cygwin.dll.  Legally, my substitute could use the
same interface, as long as I didn't copy the implementation.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Reed Kotler Consulting]

<<snip>>
>
>You seem to be confused by the fact that much GPLed code is owned
>by the FSF, including code that was written by others but ownership
>was turned over to the FSF, and perhaps by the fact that the GPL itself
>is copyrighted by the FSF.  The GPL is a document that describes the
>terms of a copyright, terms that involve the granting of software
>licenses.  The "License" in "GPL" is a license to the "General
>Public" from the owner of the copyright, not a license from the FSF.
>How could the FSF possibly have licensing rights to code owned by
>Cygnus to the exclusion of Cygnus; how were they granted such exclusive
>rights?  As opposed to code that Cygnus turned over to the FSF, such as
>BFD; cygwin.dll is not such code.  Anybody can put their code, code they
>own, code they have the copyright to, under the GPL, which happens to be
>published by the FSF.  That does not automatically give the FSF any
>special legal standing, including licensing rights.  There is nothing in
>the GPL that gives the FSF any rights to code copyrighted under it
>(other than the rights that *everyone* in the public gets).
>
>
>Really, all these issues have been discussed before and elsewhere;
>I'm not the best person to debate them with, and this isn't the
>best place to do it.  So if you think I've said something false,
>I direct you to gnu.misc.discuss (where you won't necessarily
>get the right answers either), the FSF and Cygnus legal departments,
>the U.S. Patent and Copyrights office, etc.
>
>But then, I thought you didn't care. :-)
>
Wow! I must be out of touch with all this! I guess I need to re-read
the gpl.

I think I'll skip the gnu.misc.discuss. I need one more mailing
list or newsgroup like I need a hole in my head.

Your stating that Stallman considers code derived from the bison
skelleton as being free source because it derives from bison is
pretty schocking. I've never heard anything like that!

Well I'm considerring adding gcc to the unix like toolset I distribute
for NT/windows 95. My toolset has no cygwin dependence since they were
all built with vc++ . 

I guess if I choose to distribute the cygwin dll then people
building applications could potentially have to deal with those GPL
issues. However since the cygwin dll is separately available from
other sources it seems totally safe to me but of course lawyers can
always hassle you no matter what you do. And that is what it will
come down to. For some small fry, nobody will care anyway and for
someone that has something to worry about, paying cygnus 10k or
whatever to avoid getting hassled is no big deal. Although someone
with 10k to spend may choose some competing commercial product
like nutcraker.

Has any of GPL ever been tested in court?

reed


Reed Kotler
http://www.reedkotler.com  home of a nice unix like toolset for windows NT/95
http://www.justjazz.com    home of a jazz musicians discussion list
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

Reed Kotler Consulting wrote:

> Your stating that Stallman considers code derived from the bison
> skelleton as being free source because it derives from bison is
> pretty schocking. I've never heard anything like that!

As I indicated in private e-mail, my search on dejanews suggests that
this was once the case but no longer is.  I'm mentioning that here
so I don't knowingly leave a false impression.  But we are distinctly
off topic, so let's keep this off-line.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Reed Kotler Consulting]

>> >Reed Kotler Consulting wrote:
>> >
>> >> I remember seeing this GPL thread go on and on and frankly I ignored it.
>> >>
>> >> However, I'm looking at the webpage for cygnus and seeing some
>> >> claim that if you build software using the cygwin.dll that it has
>> >> to become free software too if you don't have the commercial license.
>> >>
>> >> This seems to be a pretty far fetched reading of the GPL.
>> >
>> >Farfetched?  That seems pretty standard, since the issue is actually
>> >libcygwin.a, which incorporates portions of GPL code into
>> >your executable.  The situation is no different from using the bison
>> >parser.  If you still think that's a wrong reading, perhaps you can take
>> >it up on gnu.misc.discuss, where people like to talk about these things.
>> >
>> >--
>> Well what is libcygwin.a? Presumably just the thunks that call the
>> DLL.
>> 
>> So how can that code be under GPL?
>
>libcygwin.a also includes libccrt0, libcctype, libcerr, libcmain,
>getopt, and getopt1.  getopt* doesn't belong to Cygnus.  It would be
>quite easy to provide your own versions of the others,
>with the exception of libcmain, which would necessarily require either
>copying the cygwin code or reverse engineering it.  What a court of law
>would have to say, I dunno, but Cygnus has made their intention pretty
>clear.
>
well that's quite interesting!

I guess like you say, the key is to just not link with libcygwin.a .

I suppose thought that you could relink cygwin.dll adding those other
components and then you wouldnt be violating any rules.

In that case you could distribute your own version of cygwin.dll,
under GPL of course and then you would not be linking in any code
from cygwin.dll.

However, presumably cygnus can't enforce GPL anyway, only FSF can do 
that.

reed


Reed Kotler
http://www.reedkotler.com  home of a nice unix like toolset for windows NT/95
http://www.justjazz.com    home of a jazz musicians discussion list
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

Reed Kotler Consulting wrote:
> 
> At 02:18 PM 3/29/97 -0800, you wrote:
> >Reed Kotler Consulting wrote:
> >
> >> I remember seeing this GPL thread go on and on and frankly I ignored it.
> >>
> >> However, I'm looking at the webpage for cygnus and seeing some
> >> claim that if you build software using the cygwin.dll that it has
> >> to become free software too if you don't have the commercial license.
> >>
> >> This seems to be a pretty far fetched reading of the GPL.
> >
> >Farfetched?  That seems pretty standard, since the issue is actually
> >libcygwin.a, which incorporates portions of GPL code into
> >your executable.  The situation is no different from using the bison
> >parser.  If you still think that's a wrong reading, perhaps you can take
> >it up on gnu.misc.discuss, where people like to talk about these things.
> >
> >--
> Well what is libcygwin.a? Presumably just the thunks that call the
> DLL.
> 
> So how can that code be under GPL?

libcygwin.a also includes libccrt0, libcctype, libcerr, libcmain,
getopt, and getopt1.  getopt* doesn't belong to Cygnus.  It would be
quite easy to provide your own versions of the others,
with the exception of libcmain, which would necessarily require either
copying the cygwin code or reverse engineering it.  What a court of law
would have to say, I dunno, but Cygnus has made their intention pretty
clear.

> I guess regarding Bison you are talking about the shell code for bison.

Yes.

> Then what about libc.a from GNU?

It is copyrighted under the LGPL, not the GPL.

> It seems that almost anything ever build with GNU would fall under GPL.

To one not familiar with the issues.

> Thats a pretty novel reading of the GPL though I guess it's discussed
> somewhere by people that care.

No, it is not novel, even if you haven't heard it before.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

Reed Kotler Consulting wrote:

> >Distributing a modified cygwin.dll or putting it at an ftp site
> >separately from that which depends on it is really pushing things, and
> >seems pretty dangerous if anyone actually brought suit.
> >
> Why is that dangerous?
>
> Isnt that the whole point of GPL?
>
> You can modify the code as long as you give everyone else the
> modifications.

That wasn't the point; the point was distributing your *other* code,
the code that *depends upon* cygwin, without sharing its sources.

> >> However, presumably cygnus can't enforce GPL anyway, only FSF can do
> >> that.
> >
> >Huh?  The copyright on libcygwin.a and cygwin.dll belong to Cygnus
> >Solutions, not the FSF; the FSF just publishes the text of copyright,
> >but that doesn't give them any legal standing.  And it's the courts that
> >enforce these things.
> >
> 
> I quote from section 3 of GPL

[snipped]

> Clearly it's okay to distribute a modified cygwin if it's subject to GPL.

Yes, but that wasn't the issue.  The point was distributing some
*other* code that depends upon cygwin's code, and then distributing
cygwin's code separately, all with the clear intent of avoiding
having the conditions of the GPL enforced against your unshared code.
Suppose that you made some modifications to some GPL code,
compiled it, extracted out all bytes that result from your changes
into a patch, and distributed the binary patch.  That patch is worthless
without the executable that it patches.  So, through some other
channnel you distribute the GPL code that the patch applies to.
That is a clear circumvention of the intent of the GPL.

> In addition, it states clearly  "it is not the intent of this section to
> claim rights or contest your rights to work written entirely by you;
> rather, the intent is to exercise the right to control the distribution of
> derivative
>      or collective works based on the Program.

Right, they don't want to steal your work from you, they
just want to prevent you from distributing derived works without
sharing the source.

> In addition, mere
> aggregation of another work not based on the Program with the Program (or
> with a work based on the Program) on a volume of a storage
>      or distribution medium does not bring the other work under the scope
> of this License. "
> 
> Thus, even if you link in their .a you still don't violate GPL.

No such "thus".  Linking is not mere aggregation; it creates a derived
work.  All the precedent and prior discussion establishes that.
That is definitely the intent of the words of the GPL, as stated by its
author.

> The whole point of GPL is to prevent someone from doing something like
> taking cygwin.dll, improving it and then not letting everyone else
> have the improvements.

That's not the *whole* point; the *whole* point goes back to
Richard Stallman's personal philosophy.  Using the bison parser
in your own program is not making an improvement to the bison parser,
but it has been repeatedly been stated that such *use* of GPLed
code requires sharing source.  The express purpose of the LGPL
as opposed to the GPL is to allow such use without sharing source.
If that were not the case, there simply wouldn't be any need for the
LGPL.  Any argument you wish to make must take the LGPL into account.
 
> It's not meant, as clearly stated, to cause some "independent work" to
> be become part of GNU.

The issue is not to make it part of GNU; that is a common confusion.
The point is to *prevent you* from distributing someone's property
without obeying their express restrictions.  It is not and never
has been a matter of seizing your property; that is a misunderstanding
that that language in the GPL is meant to dispel, although it fails
to do so.  "You can't hoard the source of programs derived from ours"
does not mean "If you distribute programs derived from ours, we own
them".  Linking GPLed code into a binary is considered to create
a derived work, at least by the FSF.

> Also, it's my understanding that even if cygnus owns the copyright,
> the GPL is a license from FSF so I don't see how somebody else could
> enforce the license.

All such rights and rights to enforcement belong to the copyright
holder (that's why it's called a copy"right").
How someone can enforce their copyright is spelled out in copyright law.

You seem to be confused by the fact that much GPLed code is owned
by the FSF, including code that was written by others but ownership
was turned over to the FSF, and perhaps by the fact that the GPL itself
is copyrighted by the FSF.  The GPL is a document that describes the
terms of a copyright, terms that involve the granting of software
licenses.  The "License" in "GPL" is a license to the "General
Public" from the owner of the copyright, not a license from the FSF.
How could the FSF possibly have licensing rights to code owned by
Cygnus to the exclusion of Cygnus; how were they granted such exclusive
rights?  As opposed to code that Cygnus turned over to the FSF, such as
BFD; cygwin.dll is not such code.  Anybody can put their code, code they
own, code they have the copyright to, under the GPL, which happens to be
published by the FSF.  That does not automatically give the FSF any
special legal standing, including licensing rights.  There is nothing in
the GPL that gives the FSF any rights to code copyrighted under it
(other than the rights that *everyone* in the public gets).


Really, all these issues have been discussed before and elsewhere;
I'm not the best person to debate them with, and this isn't the
best place to do it.  So if you think I've said something false,
I direct you to gnu.misc.discuss (where you won't necessarily
get the right answers either), the FSF and Cygnus legal departments,
the U.S. Patent and Copyrights office, etc.

But then, I thought you didn't care. :-)

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Reed Kotler Consulting]

At 08:47 PM 3/30/97 -0800, Jim Balter wrote:
>Reed Kotler Consulting wrote:
>
>> I suppose thought that you could relink cygwin.dll adding those other
>> components and then you wouldnt be violating any rules.
>
>libccrt0 has to live in the .exe, not the dll.  If Cygnus had published
>an interface specification for cygwin.dll then of course you could
>just say that you were following the spec if you provided your own
>version, but they haven't.  As I said, I don't know how copyright
>law applies to reverse engineering.
>
>> In that case you could distribute your own version of cygwin.dll,
>> under GPL of course and then you would not be linking in any code
>> from cygwin.dll.
>
>Distributing a modified cygwin.dll or putting it at an ftp site
>separately from that which depends on it is really pushing things, and
>seems pretty dangerous if anyone actually brought suit.
>
Why is that dangerous?

Isnt that the whole point of GPL?

You can modify the code as long as you give everyone else the
modifications.

>> However, presumably cygnus can't enforce GPL anyway, only FSF can do
>> that.
>
>Huh?  The copyright on libcygwin.a and cygwin.dll belong to Cygnus
>Solutions, not the FSF; the FSF just publishes the text of copyright,
>but that doesn't give them any legal standing.  And it's the courts that
>enforce these things.
>

I quote from section 3 of GPL

"Section 3 -

3.You may modify your copy or copies of the Program or any portion of it,
thus forming a work based on the Program, and copy and distribute such
modifications or work under the terms of Section 1
     above, provided that you also meet all of these conditions: 
        1.You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change. 
        2.You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third
          parties under the terms of this License. 
        3.If the modified program normally reads commands interactively
when run, you must cause it, when started running for such interactive use
in the most ordinary way, to print or display an
          announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide a
warranty) and that users may redistribute the program under
          these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but does not
normally print such an announcement, your work based on the
          Program is not required to print an announcement.) 
     These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program, and
can be reasonably considered independent and separate works in
     themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work
     based on the Program, the distribution of the whole must be on the
terms of this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of
     who wrote it. Thus, it is not the intent of this section to claim
rights or contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of derivative
     or collective works based on the Program. In addition, mere
aggregation of another work not based on the Program with the Program (or
with a work based on the Program) on a volume of a storage
     or distribution medium does not bring the other work under the scope
of this License. 
"

Clearly it's okay to distribute a modified cygwin if it's subject to GPL.

In addition, it states clearly  "it is not the intent of this section to
claim rights or contest your rights to work written entirely by you;
rather, the intent is to exercise the right to control the distribution of
derivative
     or collective works based on the Program. In addition, mere
aggregation of another work not based on the Program with the Program (or
with a work based on the Program) on a volume of a storage
     or distribution medium does not bring the other work under the scope
of this License. "

Thus, even if you link in their .a you still don't violate GPL.

The whole point of GPL is to prevent someone from doing something like
taking cygwin.dll, improving it and then not letting everyone else
have the improvements.

It's not meant, as clearly stated, to cause some "independent work" to
be become part of GNU.

Also, it's my understanding that even if cygnus owns the copyright,
the GPL is a license from FSF so I don't see how somebody else could
enforce the license.

reed


>--
><J Q B>
>


Reed Kotler
http://www.reedkotler.com  home of a nice unix like toolset for windows NT/95
http://www.justjazz.com    home of a jazz musicians discussion list
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

Reed Kotler Consulting wrote:

> I suppose thought that you could relink cygwin.dll adding those other
> components and then you wouldnt be violating any rules.

libccrt0 has to live in the .exe, not the dll.  If Cygnus had published
an interface specification for cygwin.dll then of course you could
just say that you were following the spec if you provided your own
version, but they haven't.  As I said, I don't know how copyright
law applies to reverse engineering.

> In that case you could distribute your own version of cygwin.dll,
> under GPL of course and then you would not be linking in any code
> from cygwin.dll.

Distributing a modified cygwin.dll or putting it at an ftp site
separately from that which depends on it is really pushing things, and
seems pretty dangerous if anyone actually brought suit.

> However, presumably cygnus can't enforce GPL anyway, only FSF can do
> that.

Huh?  The copyright on libcygwin.a and cygwin.dll belong to Cygnus
Solutions, not the FSF; the FSF just publishes the text of copyright,
but that doesn't give them any legal standing.  And it's the courts that
enforce these things.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Reed Kotler Consulting]

At 02:18 PM 3/29/97 -0800, you wrote:
>Reed Kotler Consulting wrote:
>
>> I remember seeing this GPL thread go on and on and frankly I ignored it.
>> 
>> However, I'm looking at the webpage for cygnus and seeing some
>> claim that if you build software using the cygwin.dll that it has
>> to become free software too if you don't have the commercial license.
>> 
>> This seems to be a pretty far fetched reading of the GPL.
>
>Farfetched?  That seems pretty standard, since the issue is actually
>libcygwin.a, which incorporates portions of GPL code into
>your executable.  The situation is no different from using the bison
>parser.  If you still think that's a wrong reading, perhaps you can take
>it up on gnu.misc.discuss, where people like to talk about these things.
>
>--
Well what is libcygwin.a? Presumably just the thunks that call the
DLL.

So how can that code be under GPL?

THe microsoft (and any NT comapatable) linker generates that code.

I guess regarding Bison you are talking about the shell code for bison.

Then what about libc.a from GNU?

It seems that almost anything ever build with GNU would fall under GPL.

Thats a pretty novel reading of the GPL though I guess it's discussed
somewhere by people that care.

reed


Reed Kotler
http://www.reedkotler.com  home of a nice unix like toolset for windows NT/95
http://www.justjazz.com    home of a jazz musicians discussion list
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

Reed Kotler Consulting wrote:

> I remember seeing this GPL thread go on and on and frankly I ignored it.
> 
> However, I'm looking at the webpage for cygnus and seeing some
> claim that if you build software using the cygwin.dll that it has
> to become free software too if you don't have the commercial license.
> 
> This seems to be a pretty far fetched reading of the GPL.

Farfetched?  That seems pretty standard, since the issue is actually
libcygwin.a, which incorporates portions of GPL code into
your executable.  The situation is no different from using the bison
parser.  If you still think that's a wrong reading, perhaps you can take
it up on gnu.misc.discuss, where people like to talk about these things.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Reed Kotler Consulting]

At 07:39 PM 3/28/97 -0800, Jim Balter wrote:
>David Essex wrote:
>> 
>> Ian Lance Taylor <ian@cygnus.com> wrote:
>> 
>> >BFD, gas, ld, the binutils, are all under the GPL
>> >and always have been.  Any contributions you or anybody chooses to
>> >make will be made under the GPL, will require a copyright assignment
>> >to the Free Software Foundation, and will be included in future
>> >binutils net releases for anybody to use.
>> >
>> >The commercial licensing stuff applies only to the gnu win32 library
>> >itself, which is copyrighted by Cygnus.  It does not apply to the
>> >binutils.
>> Commercial licensing ?
>> The cygnus gnu-win32 web page says that this is free software.
>> If win32 library is part of gnu why do you need a commercial license ?
>> Could some one expand on this ?
>
>
>In addition to the GPL, Cygnus offers cygwin.dll under a restricted
>license to commercial clients who wish to use it without sharing their
>own sources.  As the owner, Cygnus has every legal right to do this.
>Whether it is consistent with the spirit of the GPL is another matter.
>There was a long, heated debate on the mailing list after Cygnus
>posted a press release announcing their intentions; no sense in
>repeating it.
>
>Note that many libraries, such as glibc, are released under the LGPL,
>not the GPL, implicitly allowing commercial users to do what commercial
>users of cygwin must pay Cygnus for a license to do.  Cygnus
>intentionally used the GPL rather than the LGPL for just this reason.
>
>--
I remember seeing this GPL thread go on and on and frankly I ignored it.

However, I'm looking at the webpage for cygnus and seeing some
claim that if you build software using the cygwin.dll that it has
to become free software too if you don't have the commercial license.

This seems to be a pretty far fetched reading of the GPL.

reed




Reed Kotler
http://www.reedkotler.com  home of a nice unix like toolset for windows NT/95
http://www.justjazz.com    home of a jazz musicians discussion list
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".