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 147

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



    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/



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


  6. Re: Glibc patent



    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



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

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



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

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

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

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

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


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


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


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


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

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

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

  20. 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錸s Rullg錼d
    mru@inprovide.com

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