Glibc patent - Linux

This is a discussion on Glibc patent - Linux ; 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 ...

+ Reply to Thread
Page 1 of 8 1 2 3 ... LastLast
Results 1 to 20 of 146

Thread: Glibc patent

  1. Glibc patent

    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?

    Thanks.
    ABAI


  2. Re: Glibc patent

    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/

  3. Re: Glibc patent

    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 =----

  4. Re: Glibc patent


    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


  5. Re: Glibc patent

    "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.

  6. Re: Glibc patent

    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



  7. Re: Glibc patent

    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.

  8. Re: Glibc patent

    ["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.

  9. Re: Glibc patent

    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.

  10. Re: Glibc patent

    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 :-).

  11. Re: Glibc patent

    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


  12. Re: Glibc patent


    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


  13. Re: Glibc patent


    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.


  14. Re: Glibc patent


    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


  15. Re: Glibc patent

    ??? 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.

  16. Re: Glibc patent

    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

  17. Re: Glibc patent

    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.

  18. Re: Glibc patent

    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

  19. Re: Glibc patent

    Måns Rullgård wrote:
    > Chris Friesen writes:


    >>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.


    Are you sure? A quick google search reveals the following:

    http://groups.google.com/group/linux...162fc81fdb710e

    Of particular note:

    'The Eleventh Circuit said that it would be "an incorrect statement of the
    law that interface specifications are not copyrightable as a matter of
    law" but did "join [the 9th, 2nd, and 5th] circuits in finding that
    external considerations such as compatibility may negate a finding of
    infringement."'


    >>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.


    I said "ABI", not "API". The discussion was for linking against glibc,
    so for that you need the binary interface.

    Chris

  20. Re: Glibc patent


    > 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.


    Certainly the design of the work could make it a derivative work. It
    would have to contain significant protectable expression from the work
    beyond what was needed just to make the two works interoperate. (The
    expression taken from the work would have to be protectable in this
    operation context, see the details below.)

    I would hope nobody would read my saying "linking doesn't create a
    derivative work" to mean that the result of a linking process can't
    ever be a work that is derivative of some other work. Linking creates a
    mechanical aggregation of the input works. If one of those input works
    is a derivative work, so is the output 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.


    But that's what's needed to make the two works interoperate. Only a
    patent can protect function, copyrights protect expression.

    To put it another way, copyrights protect an idea that can be expressed
    any number of ways and when one creative one is chosen. If including
    the Linux kernel header files is the only practical way to make a Linux
    driver for a network card, then it is the only way to express an idea,
    and in that context, is not protectable expression.

    It is funny that the GPL crowd opposes software patents but then claims
    they can protect, under copyright, all practical ways to make a Linux
    driver for an ATI X800 graphics card.

    In any event, if the work is a library, this clearly won't fly. There
    is *NO* way to use library source code other than to compile it,
    include its header files in other code, and compile, link and run that
    code. So a license to use must include the right to do those things.

    > 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.


    No, that's not the reason. The reason is in copyright law. Linus opted
    to clarify his understanding of the law in the hopes that it would
    reduce perceived risk. There were other reasons as well, but very few
    people believe that Linus can unilaterally modify the license Linux is
    shipped with and have that have any legal effect.

    > 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.


    The reduced practicality of that demonstrates that this the best way to
    express this idea. Anything that is the one best way to express an idea
    cannot be copyrighted. Copyright can only protect one particular way of
    expressing an idea that can be expressed many equally-good ways. It
    protects the creative choice of the one particular way.

    See for example Lexmark v. Static Controls. Lexmark made a printer that
    required a cartridge to contain a particular piece of software. It
    might have been possible to make another piece of software, but experts
    agreed that the most practical way to make the cartridge work with the
    printer was Lexmark's TLP program. The courts therefore held that as
    used to make a cartridge work with the printer, the TLP program was not
    protected by copryight, since it was the only practical way to do a
    particular thing (make a cartridge that worked with that printer).

    Even if the TLP contains protectable expression, when you take only
    what you need as the best practical way to interoperate, you are not
    taking protectable expression, you are taking function. Function cannot
    be copyrighted, that's what patents are for.

    Similarly, including headers from the kernel or the library is the only
    reasonably practical way to make things work with that library or OS,
    it is not one creative choice from a vast number of choices. Copyright
    does not protect only practical ways. It requires a vast number of
    equally practical ways and one creative choice.

    If I legitimately own a copy of the Linux kernel or a library, I have
    the legal right to make use of it. You cannot use copyright to stop me.
    You cannot claim that my ordinary use created a derivative work because
    takings needed for ordinary use *are* use, and use does not create
    derivative works.

    DS


+ Reply to Thread
Page 1 of 8 1 2 3 ... LastLast