In article <1164691672.746626.51020@l39g2000cwd.googlegroups.c om>,
Binary wrote:

>Any one knows the Glibs use which license?

Have you considered just downloading the package and looking?

--
http://www.spinics.net/list/gcchelp/

Binary wrote:
> Hi,
>
> Any one knows the Glibs use which license? In glibc's source code there
> is a file named 'LICENSE' which includes a lot of licenses.
> In common sense the GLIBC should be using GPL license, which means when
> a file is linked with libc.so, the source should be open?

Glibc is not patented. It is licensed under the LGPL, or GNU Lesser
Public License.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On 11ÔÂ28ÈÕ, ÏÂÎç4ʱ46·Ö, e...@no.spam () wrote:
> In article <1164691672.746626.51...@l39g2000cwd.googlegroups.c om>,
>
> Binary wrote:
> >Any one knows the Glibs use which license?Have you considered just downloading the package and looking?
I have said that I have taken the look and found a LICENSE file
including various license infomations. FYI.

>
> --http://www.spinics.net/list/gcchelp/

Binary wrote:


> Any one knows the Glibs use which license? In glibc's source code there
> is a file named 'LICENSE' which includes a lot of licenses.
> In common sense the GLIBC should be using GPL license, which means when
> a file is linked with libc.so, the source should be open?

The GPL license is generally not ideal for libraries. The LGPL exists
for this purpose.

Second, the GPL does not mean that if a file is linked with some other
file, the source should be open. This combines two very serious
misconceptions.

First, linking does not create a derivative work, which is the only
thing that can extend the GPL's authority from one work to another.
Legally, creating a derivative work must be a creative authoring
process, and linking is automated and mechanical. (Except for a few
exceptions accidentally created by statute and not relevant here.)

Second, the GPL does not require source to be open. It makes source
availability contingent on redistribution. So if a work is not
redistributed, the source need not be available. Also, the source need
only be made available to someone who lawfully received the binary.

DS

On 11ÔÂ29ÈÕ, ÉÏÎç5ʱ42·Ö, "David Schwartz"
wrote:
> Binary wrote:
> > Any one knows the Glibs use which license? In glibc's source code there
> > is a file named 'LICENSE' which includes a lot of licenses.
> > In common sense the GLIBC should be using GPL license, which means when
> > a file is linked with libc.so, the source should be open?The GPL license is generally not ideal for libraries. The LGPL exists
> for this purpose.
>
> Second, the GPL does not mean that if a file is linked with some other
> file, the source should be open. This combines two very serious
> misconceptions.
>
> First, linking does not create a derivative work, which is the only
> thing that can extend the GPL's authority from one work to another.
> Legally, creating a derivative work must be a creative authoring
> process, and linking is automated and mechanical. (Except for a few
> exceptions accidentally created by statute and not relevant here.)
What do you mean about creative? For example, we wrote a app linked
with libx.so, which is GPL'd, if I sell the app to customer, is it a
need to prepare the source to customer according to GPL?
>
> Second, the GPL does not require source to be open. It makes source
> availability contingent on redistribution. So if a work is not
> redistributed, the source need not be available. Also, the source need
> only be made available to someone who lawfully received the binary.
>
Yes, you are right, but most people asking this question is going to
distribute their binary to customers :-)
> DS

"David Schwartz" writes:
> Binary wrote:
>> Any one knows the Glibs use which license? In glibc's source code there
>> is a file named 'LICENSE' which includes a lot of licenses.
>> In common sense the GLIBC should be using GPL license, which means when
>> a file is linked with libc.so, the source should be open?
>
> The GPL license is generally not ideal for libraries. The LGPL exists
> for this purpose.

The GPL requires any derived work (see below) to be GPL-licensed as
well. The LGPL allows that a derived work which contains the original
work unmodified may have an arbitrary license under some conditions.

> Second, the GPL does not mean that if a file is linked with some other
> file, the source should be open.

Runtime-linking is basically an efficency hack and not a technically
different procedure.

> First, linking does not create a derivative work, which is the only
> thing that can extend the GPL's authority from one work to another.

And publishing novel where each odd page is a reproduction of set of
Mickey Mouse comic pictures will certainly not violate a copyright
held by Walt Disney. Or not? That would be a simple experiment to
make.

In comp.os.linux.development.system Rainer Weikusat wrote in part:
> "David Schwartz" writes:
>> Second, the GPL does not mean that if a file is linked with some other
>> file, the source should be open.
>
> Runtime-linking is basically an efficency hack and not a technically
> different procedure.

It could be. Static linking includes the lib and needs some sort
of licence, eg the LGPL. Runtime linking could be against a lib
distributed and licenced by other means. I doubt even Microsoft
would dare stick into their OS licence [EULA] "KERNEL.DLL and other
software can only be used to run other MS software". I'm pretty
sure any US judge would throw that out as an illegal restraint of
trade and attempt to extend monopoly.


>> First, linking does not create a derivative work, which is the only
>> thing that can extend the GPL's authority from one work to another.

> And publishing novel where each odd page is a reproduction of
> set of Mickey Mouse comic pictures will certainly not violate
> a copyright held by Walt Disney. Or not? That would be a simple
> experiment to make.

But not quite a valid analogy. Linked subroutines are structurally
subordinate and of lesser importance to higher pgm lines. Pages in
a novel are all equal. A closer analogy would be a novel with
references to another for how to do some step. Eg: In a book
"perfect partying", a reference to go read "The Joy of Cooking"
p.xxx for a certain recipe.

-- Robert

Rainer Weikusat writes:

> "David Schwartz" writes:
>> Binary wrote:
>>> Any one knows the Glibs use which license? In glibc's source code there
>>> is a file named 'LICENSE' which includes a lot of licenses.
>>> In common sense the GLIBC should be using GPL license, which means when
>>> a file is linked with libc.so, the source should be open?
>>
>> The GPL license is generally not ideal for libraries. The LGPL exists
>> for this purpose.
>
> The GPL requires any derived work (see below) to be GPL-licensed as
> well. The LGPL allows that a derived work which contains the original
> work unmodified may have an arbitrary license under some conditions.
>
>> Second, the GPL does not mean that if a file is linked with some other
>> file, the source should be open.
>
> Runtime-linking is basically an efficency hack and not a technically
> different procedure.

How is it an efficiency hack? Define "efficiency" in this instance.

["Followup-To:" header set to comp.os.linux.development.system.]
On Wed, 29 Nov 2006 15:45:46 GMT, Robert Redelmeier wrote:

>>> First, linking does not create a derivative work, which is the only
>>> thing that can extend the GPL's authority from one work to another.
>
>> And publishing novel where each odd page is a reproduction of
>> set of Mickey Mouse comic pictures will certainly not violate
>> a copyright held by Walt Disney. Or not? That would be a simple
>> experiment to make.
>
> But not quite a valid analogy. Linked subroutines are structurally
> subordinate and of lesser importance to higher pgm lines. Pages in
> a novel are all equal. A closer analogy would be a novel with
> references to another for how to do some step. Eg: In a book
> "perfect partying", a reference to go read "The Joy of Cooking"
> p.xxx for a certain recipe.

Closer still would be a reference to another book for a key without
which none of the book in hand can be read.

Robert Redelmeier writes:
> Rainer Weikusat wrote in part:
>> "David Schwartz" writes:
>>> Second, the GPL does not mean that if a file is linked with some other
>>> file, the source should be open.
>>
>> Runtime-linking is basically an efficency hack and not a technically
>> different procedure.
>
> It could be.

That should read 'by carefully twisting and selectively ignoring the
facts, I could make a sufficiently non-technical person believe this'
....

> Static linking includes the lib and needs some sort
> of licence, eg the LGPL. Runtime linking could be against a lib
> distributed and licenced by other means.

'Runtime linking' includes the library just the same, except that it
happens at runtime.

> I doubt even Microsoft would dare stick into their OS licence [EULA]
> "KERNEL.DLL and other software can only be used to run other MS
> software".

They would have every right to do that, but for 'obvious reasons' (ISV
support), they license their DLLs differently.

>>> First, linking does not create a derivative work, which is the only
>>> thing that can extend the GPL's authority from one work to another.
>
>> And publishing novel where each odd page is a reproduction of
>> set of Mickey Mouse comic pictures will certainly not violate
>> a copyright held by Walt Disney. Or not? That would be a simple
>> experiment to make.
>
> But not quite a valid analogy. Linked subroutines are structurally
> subordinate and of lesser importance to higher pgm lines.

That is a nonsense-argument because copyright 'knows' nothing about
program structure, but about copying.

> Pages in a novel are all equal.

Subroutines in a completely-linked binary are 'all equal' as well.

> A closer analogy would be a novel with references to another for how
> to do some step.

I wouldn't: Nothing is physically (or at least as physically as
software can be) combined.

Hadron Quark writes:
> Rainer Weikusat writes:
>> "David Schwartz" writes:
>>> Binary wrote:
>>>> Any one knows the Glibs use which license? In glibc's source code there
>>>> is a file named 'LICENSE' which includes a lot of licenses.
>>>> In common sense the GLIBC should be using GPL license, which means when
>>>> a file is linked with libc.so, the source should be open?
>>>
>>> The GPL license is generally not ideal for libraries. The LGPL exists
>>> for this purpose.
>>
>> The GPL requires any derived work (see below) to be GPL-licensed as
>> well. The LGPL allows that a derived work which contains the original
>> work unmodified may have an arbitrary license under some conditions.
>>
>>> Second, the GPL does not mean that if a file is linked with some other
>>> file, the source should be open.
>>
>> Runtime-linking is basically an efficency hack and not a technically
>> different procedure.
>
> How is it an efficiency hack? Define "efficiency" in this instance.

Sorry, but if this isn't self-evident to you, than I suggest that you
get yourself some introductory-style book and read that. I am not an
interactive tutorial :-).

In comp.os.linux.development.system Rainer Weikusat wrote in part:
> Robert Redelmeier writes:
>> Static linking includes the lib and needs some sort
>> of licence, eg the LGPL. Runtime linking could be
>> against a lib distributed and licenced by other means.
>
> 'Runtime linking' includes the library just the same,
> except that it happens at runtime.

Yes, and copied from a different source into RAM. The RAM
copy is considered part of "fair use", at least in the US.

>> I doubt even Microsoft would dare stick into their OS
>> licence [EULA] "KERNEL.DLL and other software can only be
>> used to run other MS software".

> They would have every right to do that, but for 'obvious
> reasons' (ISV support), they license their DLLs differently.

As I mentioned in the portion you snipped, MS cannot.
Attempting to do so is illegal under US antitrust law.

> That is a nonsense-argument because copyright 'knows'
> nothing about program structure, but about copying.

True enough. What matters is from where it was copied
and the extent of the copying. Libs, especially for
standard languages, would be viewed as "too distant"
to qualify as creating derivative works.

> Subroutines in a completely-linked binary are 'all equal'
> as well.

Yes, and the creator had better have a licence for those libs
statically included. Most compilers provide such a licence,
or no-one would use them.

-- Robert

Rainer Weikusat wrote:

> > First, linking does not create a derivative work, which is the only
> > thing that can extend the GPL's authority from one work to another.

> And publishing novel where each odd page is a reproduction of set of
> Mickey Mouse comic pictures will certainly not violate a copyright
> held by Walt Disney. Or not? That would be a simple experiment to
> make.

It would violate the copyright, for one of two reasons, both of which
prove my point.

One argument would be that the result is a derivative work because the
choice to alternate pages of those particular works is creative. You
would then be violating the copyright because you have no right to
create derivative works of Mickey Mouse. I find this argument weak, but
it's always possible a court could accept it. Linking is definitely not
creative in this sense.

The other argument would be that the result is not a derivative work
but a mere combination or compilation. In this case, you would be
violating the copyright because you have no right to distribute
verbatim copies of Mickey Mouse comic pictures.

However, if we were in the second case (as we are with linking) and
unlimited copies of Mickey Mouse comic pictures were available without
an EULA (as they are with GPL'd works) then you would not be violating
the copyright. You are not creating a derivative work, and 17 USC
109(a) makes the redistribution lawful.

DS

David Schwartz wrote:
> Binary wrote:
>
>
> > Any one knows the Glibs use which license? In glibc's source code there
> > is a file named 'LICENSE' which includes a lot of licenses.
> > In common sense the GLIBC should be using GPL license, which means when
> > a file is linked with libc.so, the source should be open?
>
> The GPL license is generally not ideal for libraries. The LGPL exists
> for this purpose.
>
> Second, the GPL does not mean that if a file is linked with some other
> file, the source should be open.

Actually it does, even if the lining is dynamic. The LGPL does not.

> This combines two very serious misconceptions.
>
> First, linking does not create a derivative work, which is the only

That's a legal conjecture which can only be tested in court.

> thing that can extend the GPL's authority from one work to another.
> Legally, creating a derivative work must be a creative authoring
> process, and linking is automated and mechanical.

No. Simply redistributing a work with any change whatsoever creates a
derivative work.

Compiling is also automated and mechanical.

> Second, the GPL does not require source to be open. It makes source
> availability contingent on redistribution. So if a work is not
> redistributed, the source need not be available.

But if you redistribute executables (for example) which dynamically
link a GPL ibrary, then their source does need to be available. That is
not the case if the library is LGPL.

You might want to read this:

http://clisp.cvs.sourceforge.net/cli...L?revision=1.1

It's an archive of some e-mails exchanged between RMS and the
developers of CLISP, who thought it would be okay to use the readline
library, if the linking step was left to the user. The user could
choose to link a readline-compatible stub library, or readline itself,
without recompiling anything in CLISP. Yet RMS convinced these
developers that their use was infringing, and as a result, they agreed
to release CLISP under the GNU license.

> Also, the source need only be made available to someone who lawfully received the binary.

That goes without saying. Imagine someone breaking into your company,
stealing some in-house GPL-derived software in binary form, and then
contacting you, demanding the source.

Kaz Kylheku wrote:

> > First, linking does not create a derivative work, which is the only

> That's a legal conjecture which can only be tested in court.

It's obvious common sense that a derivative work cannot be created by
an automated non-creative process. The only exceptions are ones
accidentally created by statute because at the time the statutes were
written, it was assumed that things like translation would necessarily
be creative processes.

Find me *one* lawyer who will say that an automated non-creative
mechanical process can create a new work for copyright purposes that
did not exist before the process. (Other than a language translation
due to the wrinkle in the statutes.)

> > thing that can extend the GPL's authority from one work to another.
> > Legally, creating a derivative work must be a creative authoring
> > process, and linking is automated and mechanical.

> No. Simply redistributing a work with any change whatsoever creates a
> derivative work.

Nonsense. Redistributing a work does not create a new work. It creates
copies of the original work.

It is absolute complete nonsense to say that if I mail you a purchased
copy of a Sting CD, I am creating a derivative work of that CD.

> Compiling is also automated and mechanical.

I agree. Compiling cannot create a derivative work if there was not one
already.

For example, if someone downloads a GPL'd work onto a machine, and runs
'./configure && make' and tars up the result, the result is the
original work, not a derivative work. (Assuming the particular way he
configured and made wasn't creative.)

In any event, if you want to argue that such trivial things create
derivative works, you wind up destroying your own argument. Suppose,
for example, that compiling the Linux kernel creates a derivative work.
It is impossible to engage in the normal, expected use of the Linux
kernel without compiling it.

When the GPL grants you the unrestricted right to *use* a work, it must
include anything necessary to use the work. (There is no such thing as
"the right to use my car, but not the right to go in my car.)

So even assuming such things created derivative works (which they do
not, there is clearly insufficient creative content), they would be
authorized by 17 USC 109 (which basically says if you legally acquire a
work, you automatically have the right to use it).

> > Second, the GPL does not require source to be open. It makes source
> > availability contingent on redistribution. So if a work is not
> > redistributed, the source need not be available.

> But if you redistribute executables (for example) which dynamically
> link a GPL ibrary, then their source does need to be available. That is
> not the case if the library is LGPL.

If and only if those executables themselves are derivative works of the
library not made during the ordinary use of that library.

> You might want to read this:
>
> http://clisp.cvs.sourceforge.net/cli...L?revision=1.1

> It's an archive of some e-mails exchanged between RMS and the
> developers of CLISP, who thought it would be okay to use the readline
> library, if the linking step was left to the user. The user could
> choose to link a readline-compatible stub library, or readline itself,
> without recompiling anything in CLISP. Yet RMS convinced these
> developers that their use was infringing, and as a result, they agreed
> to release CLISP under the GNU license.

RMS' argument is obvious nonsense. If we accepted his argument, that
would mean that if I wrote a new C standard library that existing
programs could dynamically link to, all those works would somehow
become retroactively derivative works of the library I just wrote.

> > Also, the source need only be made available to someone who lawfully received the
> > binary.

> That goes without saying. Imagine someone breaking into your company,
> stealing some in-house GPL-derived software in binary form, and then
> contacting you, demanding the source.

Exactly. Lawfully receiving a copyrighted work automatically grants you
the right to use and redistribute (transfer) that partcular copy. This
right to use includes all steps necessary for the ordinary and expected
use.

DS

??? Kaz Kylheku wrote:
[...]
> > The GPL license is generally not ideal for libraries. The LGPL exists
> > for this purpose.
> >
> > Second, the GPL does not mean that if a file is linked with some other
> > file, the source should be open.
>
> Actually it does, even if the lining is dynamic. The LGPL does not.

So says the GPL FAQ. It stems from the GNU manifesto.

>
> > This combines two very serious misconceptions.
> >
> > First, linking does not create a derivative work, which is the only
>
> That's a legal conjecture which can only be tested in court.

So go ahead and test it.

>
> > thing that can extend the GPL's authority from one work to another.
> > Legally, creating a derivative work must be a creative authoring
> > process, and linking is automated and mechanical.
>
> No. Simply redistributing a work with any change whatsoever creates a
> derivative work.

What? [Re]distribution as such doesn't create any any copyright related
work.

The exclusive distribution right is about pirated copies (material
objects) NOT "lawfully made". 17 USC 109.

>
> Compiling is also automated and mechanical.

Yes and?

>
> > Second, the GPL does not require source to be open. It makes source
> > availability contingent on redistribution. So if a work is not
> > redistributed, the source need not be available.
>
> But if you redistribute executables (for example) which dynamically
> link a GPL ibrary, then their source does need to be available. That is
> not the case if the library is LGPL.
>
> You might want to read this:
>
> http://clisp.cvs.sourceforge.net/cli...L?revision=1.1

Of course.

Read also this "fabricated responses" thread.

http://xfree86.org/pipermail/forum/2...ch/004301.html
http://xfree86.org/pipermail/forum/2...il/004306.html
http://xfree86.org/pipermail/forum/2...il/004308.html
http://xfree86.org/pipermail/forum/2...il/004309.html
http://xfree86.org/pipermail/forum/2...il/004321.html
http://xfree86.org/pipermail/forum/2...il/004353.html
http://xfree86.org/pipermail/forum/2...il/004358.html
http://xfree86.org/pipermail/forum/2...il/004384.html

regards,
alexander.

David Schwartz wrote:

> First, linking does not create a derivative work, which is the only
> thing that can extend the GPL's authority from one work to another.
> Legally, creating a derivative work must be a creative authoring
> process, and linking is automated and mechanical. (Except for a few
> exceptions accidentally created by statute and not relevant here.)

I would suggest that the issue is not the act of linking, but the very
design of the work.

If I include a GPL'd header file in my source file, then my work is
derivative of that header file (because I'm making use of the
information contained within it) and thus the GPL applies to
distribution of my application.

The only reason that it is possible to make use of linux kernel header
files when writing userspace programs is that the kernel source code
specifically exempts from consideration "programs that use kernel
services by normal system calls". Otherwise they would be impacted by
their use of GPL'd header files.

If someone did a clean-room reverse-engineering of the glibc ABI and
wrote a spec for it, and someone else implemented from scratch a way to
interface with that ABI, then you might be able to get away with calling
it "reverse engineering for purposes of interoperability" and not fall
under the GPL.



Chris

Rainer Weikusat writes:

> Hadron Quark writes:
>> Rainer Weikusat writes:
>>> "David Schwartz" writes:
>>>> Binary wrote:
>>>>> Any one knows the Glibs use which license? In glibc's source code there
>>>>> is a file named 'LICENSE' which includes a lot of licenses.
>>>>> In common sense the GLIBC should be using GPL license, which means when
>>>>> a file is linked with libc.so, the source should be open?
>>>>
>>>> The GPL license is generally not ideal for libraries. The LGPL exists
>>>> for this purpose.
>>>
>>> The GPL requires any derived work (see below) to be GPL-licensed as
>>> well. The LGPL allows that a derived work which contains the original
>>> work unmodified may have an arbitrary license under some conditions.
>>>
>>>> Second, the GPL does not mean that if a file is linked with some other
>>>> file, the source should be open.
>>>
>>> Runtime-linking is basically an efficency hack and not a technically
>>> different procedure.
>>
>> How is it an efficiency hack? Define "efficiency" in this instance.
>
> Sorry, but if this isn't self-evident to you, than I suggest that you
> get yourself some introductory-style book and read that. I am not an
> interactive tutorial :-).

No, please point your definition of efficiency : taking into account run
time over heads & problems with non matching libraries.

Chris Friesen writes:

> David Schwartz wrote:
>
>> First, linking does not create a derivative work, which is the only
>> thing that can extend the GPL's authority from one work to another.
>> Legally, creating a derivative work must be a creative authoring
>> process, and linking is automated and mechanical. (Except for a few
>> exceptions accidentally created by statute and not relevant here.)
>
> I would suggest that the issue is not the act of linking, but the very
> design of the work.
>
> If I include a GPL'd header file in my source file, then my work is
> derivative of that header file (because I'm making use of the
> information contained within it) and thus the GPL applies to
> distribution of my application.

Wrong. Interface specifications, such as those found in header files,
are not covered by copyright. Comments in a header file may be
covered, but those are not included in the compiled program anyway.

> The only reason that it is possible to make use of linux kernel header
> files when writing userspace programs is that the kernel source code
> specifically exempts from consideration "programs that use kernel
> services by normal system calls". Otherwise they would be impacted by
> their use of GPL'd header files.

That note is merely an explicit statement of facts that would be true
even without it.

> If someone did a clean-room reverse-engineering of the glibc ABI and
> wrote a spec for it, and someone else implemented from scratch a way
> to interface with that ABI, then you might be able to get away with
> calling it "reverse engineering for purposes of interoperability" and
> not fall under the GPL.

It's much simpler than that. Just download the specification from
opengroup.org and write your own implementation. It's been done many
times.

--
Måns Rullgård
mru@inprovide.com