module license taints kernel. - Linux

This is a discussion on module license taints kernel. - Linux ; On Nov 20, 9:14 am, Bob Tennent wrote: > But one cannot distribute or modify a copyrighted work except as > licensed by the copyright holder; Yes, but you have to understand the technical definitions of "distribute" and "modify" as ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 41

Thread: module license taints kernel.

  1. Re: module license taints kernel.

    On Nov 20, 9:14 am, Bob Tennent wrote:

    > But one cannot distribute or modify a copyrighted work except as
    > licensed by the copyright holder;


    Yes, but you have to understand the technical definitions of
    "distribute" and "modify" as they are used in this context.

    > so that would apply to a non-creative
    > modification as well.


    You are using the word "modify" in its commonsense meaning, not its
    precise technical meaning. In copyright law, you are not prohibit from
    "modifying" in the ordinary sense, you are prohibit from creating
    derivative works. A "non-creative modification" does not create a
    derivative work, in general.

    > In any case, linking with a non-GPLed module isn't like this. The
    > linking may be non-creative and automatic, but the module itself isn't.


    If I take a DVD of The Lion King and a DVD of The Phantom Menace, I
    can put them in the same box without creating a derivative work. This
    is so even though each of the two works I put in the box are creative.
    The question is, can I put them in the box? And the answer depends
    upon what "putting in the box" does, not on what the original works
    are.

    Legally, an automated combining process does nothing. It's no
    different from putting two DVDs in the same box. It's a non-creative
    combination.

    > We're not getting anywhere. All I can say is: tell it to the judge.


    See Lexmark v. Static Controls.

    DS

  2. Re: module license taints kernel.

    On Wed, 21 Nov 2007 15:41:57 -0800 (PST), David Schwartz wrote:

    > If I take a DVD of The Lion King and a DVD of The Phantom Menace, I
    > can put them in the same box without creating a derivative work. This
    > is so even though each of the two works I put in the box are creative.
    > The question is, can I put them in the box? And the answer depends
    > upon what "putting in the box" does, not on what the original works
    > are.


    But we're not just talking of putting two works in a box, or even of
    using the (linked) combination, but of copying them and distributing
    them. And if one of the works is GPLed, copying and distributing it is
    on its terms.

    > See Lexmark v. Static Controls.


    Presumably that would mean something to a lawyer but IANAL.

    Bob T.

  3. Re: module license taints kernel.

    On Nov 20, 11:11 am, Rainer Weikusat wrote:

    > Wether the fact that a tool is not capable of operating on its own has
    > any relevancy wrt properties of what the person using the tool was
    > using the tool for, presumably.


    There are very few legal consequences of the operational
    characteristics of a work in copyright. Copyright applies pretty much
    the same to functional works (like computer programs) as it does to
    purely aesthetic works (like abstract art).

    The only difference that matters here is that functionality is
    explicitly *removed* from copyright protection. Any functional issues
    can only reduce the scope of the GPL because it cannot cover pure
    functionality, only expression.

    You are correct, of course, that a linker can't link anything unless a
    human tells it to do so. I could imagine cases where, theoretically,
    someone might creatively command a linker to do something. However, in
    the vast majority of cases, and all the ones that matter here, the
    linking step is purely functional with its characteristics completely
    dominated by functional considerations.

    It is more like putting bolt on a nut than writing a book. The
    functional parts are combined so that they function.

    > >> That's why it is different from what I had been writing about, namely,
    > >> files intended to be linked together using an interface specific to
    > >> one of them, eg Linux kernel modules.

    >
    > > Why do you think this matters?

    >
    > Hmm ... why do you think it doesn't, taking into account that
    > 'derivative works' exist?


    I think you misunderstand what a derivative work is. A derivative work
    is a creative extension of a work such that the "new" work contains
    expressive elements taken from the original work beyond that required
    by mere functional considerations.


    > > No. Function is completely irrelevant. Really.

    >
    > It is not 'completely irrelevant' because we are arguing about
    > computer software here and 'having a function' is a necessary property
    > of computer software and 'having a different function than ...' means
    > that what has a different function than ... is a different software
    > than ... (sufficient, but not necessary condition).


    What possible relevance do you think this has to copyright law?
    Copyright law would cover in precisely the same way software that had
    no function whatsoever. In fact, when you consider copyright issues,
    you must *erase* all functional aspects from the equation because
    functionality is explicitly *exempt* from copyright.

    In other words, if you are considering whether work X is a derivative
    work of work Y, the first thing you must do is *eliminate* any aspects
    of X that are constrained by functionality requirements. You then look
    at the *expressive* elements of Y and say, "Which of them are in X?
    How have they been changed?"

    You seem to think the functional elements get more weight when in
    truth they get less.

    If would be much worse to take a comment's choice of wording than to
    take a brilliant optimization. For example, in one case where one
    company was accused of stealing elements of another map, the main
    focus wound up on the way street names were placed in areas where they
    all wouldn't fit in the most obvious places and lines or arrows were
    needed. Why? Because *no* functional considerations controlled this
    placement, it was purely a creative exercise.

    The parts about the real working parts being taken were dismissed.
    Why? Because they were dominated by functional requirements and thus
    *not* protectable by copyright.

    Note that with patents, it is the opposite.

    > > Yes, provided this process is creatively selective.


    > The process may additionally have been creatively selective, but the
    > important property of it was the creation of a derivative work by
    > combining existing parts with new parts so that something 'new'
    > results from this (see paragraph above), with the new parts having
    > been created in a way that renders them useless, except when combined
    > with the specific existing parts which were used. A practical example
    > of this would be a codec-plugin developed for a particular
    > audio-player.


    But linking never combines anything with new parts. It only combines
    existing parts.

    Presumably, a codec-plugin developed for a particular audio-player
    would only take the functional bits of the audio-player that it needs
    to plug in. This is not protectable by copyright because it's purely
    functional.

    Now, suppose the API exchanged compressed audio and the codec took
    into its own code the compressor from the audio player. Then there
    would be a question of whether the compressor code was dominated by
    functional considerations or whether the same functionality could have
    been obtained other ways, say by rewriting that code.

    But it's quite obvious that it's practically impossible to replicate
    the linux kernel interface with independent code. The interface is way
    more functional than practical.

    Copyright only covers one choice out of millions of equally practical
    choices. It does not apply when one way to get the job is way more
    practical than others. Again, see Lexmark v. Static Controls. Taking
    Lexmark's TLP code was the only practical way for Static Controls to
    make a toner cartridge that worked with Lexmark's printers, thus
    Static Controls could take it without impacting copyright.

    > > The problem is that linkers are not creatively selective.

    >
    > Things are never creative, otherwise, they would be people (side
    > remark: Does this hold when reversed? :->>).


    Exactly. Things can never produce derivative works, only creative
    combination by a human can. The module code either is or is not a
    derivative work of the kernel, regardless of whether or not anyone
    links it or can link it.

    > >> If I know 'cleverly' distribute only the part I created and add some
    > >> instructions like 'download this file from there and this other file
    > >> from here and combine them in such-and-such a way', this would still
    > >> be a derivative work, because my creation has been designed as such.

    >
    > > No, sorry. It would not.

    >
    > So, obviously, since all software can be split into parts, no software
    > can ever be a derivative work of any other software?


    Software can be a derivative work of other software if it contains
    protectable expressive elements of that other work that have been
    creatively extended beyond any practical need imposed by functional
    considerations.

    > > Until you combine your own creative expression with the creative
    > > expression of the original work, it's still just the original work.

    >
    > Well. The example assumed that I did combine it.


    The creative expression was not combined with the original work. The
    quintissential example would be turning a book into a move. There, the
    creative decisions of the book (character names, relationships,
    precise events) are creatively transformed so that the same creative
    elements are re-expressed.

    DS

  4. Re: module license taints kernel.

    David Schwartz writes:

    [...]

    I am skipping although obviouesnesses because there
    is no need to argue every misunderstanding to death.

    > Software can be a derivative work of other software if it contains
    > protectable expressive elements of that other work that have been
    > creatively extended beyond any practical need imposed by functional
    > considerations.


    Ergo: Software cannot be a derivative work of other software, except
    maybe, it if contains modified comments of non-techniccal nature,
    because anything else is imposed by functional considerations.

  5. Re: module license taints kernel.

    On Nov 21, 3:53 pm, Bob Tennent wrote:

    > But we're not just talking of putting two works in a box, or even of
    > using the (linked) combination, but of copying them and distributing
    > them.


    No. Putting a DVD of the Lion King and a DVD of The Phantom Menace in
    a box is not copying. Shipping that box to a friend is not
    distributing.

    In any event, the GPL grants you the right to copy and distribute the
    original works. For copyright purposes, the result of linking is the
    original works.

    > And if one of the works is GPLed, copying and distributing it is
    > on its terms.


    Right, except no copying or distributing is needed. I can download 100
    copies of the Linux kernel from kernel.org, and I can put them on CD
    and give them to 100 of my friends without either copying or
    distributing the kernel, legally speaking.

    > > See Lexmark v. Static Controls.

    >
    > Presumably that would mean something to a lawyer but IANAL.


    This is a case where Static Controls copied and distributed an entire
    piece of software made by Lexmark. Lexmark sued them for DMCA and
    other copyright violations. The court held that because Static
    Controls took only what it needed to make its toner cartridges work
    with Lexmark printers, there was no copyright violation.

    You can take what you need from the kernel to make your module work
    with it. Copyright does not cover what you need to make something
    work. Only patent does that. Copyright covers one choice out of
    millions of equally good ones.

    DS

  6. Re: module license taints kernel.

    On Nov 22, 12:05 am, Rainer Weikusat wrote:

    > > Software can be a derivative work of other software if it contains
    > > protectable expressive elements of that other work that have been
    > > creatively extended beyond any practical need imposed by functional
    > > considerations.


    > Ergo: Software cannot be a derivative work of other software, except
    > maybe, it if contains modified comments of non-techniccal nature,
    > because anything else is imposed by functional considerations.


    Oddly, that's true. Functional works effectively get less copyright
    protection than non-functional ones. The more a design is mandated by
    functional requirements, the less it is protected by copyright.

    This is necessary to stop copyrights from becoming patents. Patents
    give you this more powerful protection of functional elements, but
    they are much stricter requirements you have to meet to get them.

    You should definitely read Lexmark v. Static Controls. Here Static
    Controls "stole" an entire piece of software written by Lexmark. But
    they demonstrate that it was the only practical way to get their toner
    cartridges to work in Lexmark printers. Thus they only took functional
    elements and no copyright violation occurred despite the copying and
    distributing.

    DS

  7. module license taints kernel.

    DS> You will [not] find anything about
    DS> "larger programs" or linking in copyright law.

    You will, however, find a definition of an "adaptation" of a computer
    program in section 21 of the U.K. Copyrights, Designs, and Patents Act
    (as amended).

  8. Re: module license taints kernel.

    David Schwartz writes:

    > No. Putting a DVD of the Lion King and a DVD of The Phantom Menace in
    > a box is not copying. Shipping that box to a friend is not
    > distributing.
    >
    > In any event, the GPL grants you the right to copy and distribute the
    > original works. For copyright purposes, the result of linking is the
    > original works.


    It grants you those rights, given that you obey the GPL. Not otherwise.

    These requirements apply to the modified work as a whole. If
    identifiable sections of that work are not derived from the Program,
    and can be reasonably considered independent and separate works in
    themselves, then this License, and its terms, do not apply to those
    sections when you distribute them as separate works. But when you
    distribute the same sections as part of a whole which is a work
    based on the Program, the distribution of the whole must be on the
    terms of this License, whose permissions for other licensees extend
    to the entire whole, and thus to each and every part regardless of
    who wrote it.

    When you distribute the sections you wrote yourself as part of a whole
    which is a work based on the program the distribution of the whole
    must be on the terms of the GPL - and wouldn't the kernel combined
    with your module clearly be such such a whole?

    You may distribute your non-derived work as you please, but you may
    not distribute the GPL:ed program together whith it, if they form a
    "whole", i.e. if they _combined_ are a derivative work. In the
    aggregate you surely use creative expression from the original work.

    Mere aggregation on a distribution medium is not covered, but I have a
    hard time finding putting your module in /lib/modules/* being mere
    aggregation on a distribution medium. You seem to argue that even the
    running kernel is a "mere aggregation" of independent works. That
    sounds crazy.

    >> And if one of the works is GPLed, copying and distributing it is
    >> on its terms.

    >
    > Right, except no copying or distributing is needed. I can download 100
    > copies of the Linux kernel from kernel.org, and I can put them on CD
    > and give them to 100 of my friends without either copying or
    > distributing the kernel, legally speaking.


    Maybe. But then that kernel _is_ tainted. It cannot be distributed by
    folks downstream either.

    And I think you _are_ making copies already by downloading the program
    from kernel.org (at least that is the case legally where I live).
    You could have somebody else download those copies, but that should be
    an independent entity.

    > This is a case where Static Controls copied and distributed an entire
    > piece of software made by Lexmark. Lexmark sued them for DMCA and
    > other copyright violations. The court held that because Static
    > Controls took only what it needed to make its toner cartridges work
    > with Lexmark printers, there was no copyright violation.


    I am not familiar with your local legislation, so studying the case
    would be quite much work. And local case law isn't very important, as
    we talk about an international product. I think however, that handling
    copies of a GPL product in a way that obviously isn't meant to be
    allowed by the license, is something that would require lawyers in every
    legislation where the product is going to be distr^H^H^H^H^sold. It
    may also give you more badwill than you want to have.

    > You can take what you need from the kernel to make your module work
    > with it. Copyright does not cover what you need to make something
    > work. Only patent does that. Copyright covers one choice out of
    > millions of equally good ones.


    But the intent of the license may influence whether you and your
    customers are allowed to do anything that requires permission from the
    copyright holders. At least over here.

    --
    Lajos Parkatti

  9. Re: module license taints kernel.

    On Nov 26, 11:24 am, Lajos Parkatti ISES
    wrote:

    > > In any event, the GPL grants you the right to copy and distribute the
    > > original works. For copyright purposes, the result of linking is the
    > > original works.


    > It grants you those rights, given that you obey the GPL. Not otherwise.


    Unfortunately this gets extremely technical. I wish I could explain it
    in simple terms but I really can't. The answer comes from two places:

    1) You are confusing *who* needs to comply with the GPL. If you
    distribute and copy a GPL'd work and I get a copy, that doesn't mean
    that *I* need to comply with the GPL, it only means you do.

    2) You can't use a license to create copyright violation claims based
    on violation of that license. In other words, you can't use a license
    to make failure to release source code a copyright violation.

    > When you distribute the sections you wrote yourself as part of a whole
    > which is a work based on the program the distribution of the whole
    > must be on the terms of the GPL - and wouldn't the kernel combined
    > with your module clearly be such such a whole?


    The answer to whether it clearly is -- no. If the module is not a
    derivative work of the kernel, then the two of them combined cannot be
    either. In that case, it's likely not a "work based on the program"
    because it's not a work. Linkers don't create works, people do.

    > You may distribute your non-derived work as you please, but you may
    > not distribute the GPL:ed program together whith it, if they form a
    > "whole", i.e. if they _combined_ are a derivative work. In the
    > aggregate you surely use creative expression from the original work.


    Clearly they are not if they are combined by a linker. A linker can't
    create a new work, so it can't create a derivative work where there
    wasn't one before.

    If you write a C program and I write a 'malloc' replacement, the two
    of them linked together is not a work unless the linker was invoked in
    some creative way.

    > Mere aggregation on a distribution medium is not covered, but I have a
    > hard time finding putting your module in /lib/modules/* being mere
    > aggregation on a distribution medium. You seem to argue that even the
    > running kernel is a "mere aggregation" of independent works. That
    > sounds crazy.


    That's exactly what I'm arguing. That a linker is just like tar+gzip.
    Any *non-creative* process that methodically copies bits and pieces of
    the works and combines them is a mere aggregator. The opposite of
    "mere aggregation" is creatively selective combination and extension.

    > > Right, except no copying or distributing is needed. I can download 100
    > > copies of the Linux kernel from kernel.org, and I can put them on CD
    > > and give them to 100 of my friends without either copying or
    > > distributing the kernel, legally speaking.


    > Maybe. But then that kernel _is_ tainted. It cannot be distributed by
    > folks downstream either.


    Nonsense. You have serious misunderstandings about how the GPL works.
    Please read section 6 *very* carefully. People who redistribute
    modified or unmodified GPL and BSD licensed works *NEVER* relicense
    those works. The licenses always flow from the original author(s) to
    the final recipients.

    > And I think you _are_ making copies already by downloading the program
    > from kernel.org (at least that is the case legally where I live).
    > You could have somebody else download those copies, but that should be
    > an independent entity.


    Nope. One copy flows over the network, is converted to the copy on
    your disk, and that's that. One copy is all there is. The person who
    sends it to you may arguably be copying (one copy on the disk, one on
    the network, neither goes away since the recipient can make the
    network copy persistent).

    You don't need to agree to the GPL to receive and use a GPL'd work.
    The GPL is not a shrink-wrap agreement or EULA.

    > > This is a case where Static Controls copied and distributed an entire
    > > piece of software made by Lexmark. Lexmark sued them for DMCA and
    > > other copyright violations. The court held that because Static
    > > Controls took only what it needed to make its toner cartridges work
    > > with Lexmark printers, there was no copyright violation.


    > I am not familiar with your local legislation, so studying the case
    > would be quite much work. And local case law isn't very important, as
    > we talk about an international product. I think however, that handling
    > copies of a GPL product in a way that obviously isn't meant to be
    > allowed by the license, is something that would require lawyers in every
    > legislation where the product is going to be distr^H^H^H^H^sold. It
    > may also give you more badwill than you want to have.


    The points I'm making are not minor legal technicalities, they are
    fundamental things about how copyright works. As for badwill, quite
    the opposite, the badwill results from people who try to restrict what
    other people can do with what is theirs, not from people who exercise
    the freedoms they have.

    Wouldn't the free software movement be a bunch of crazy hypocrites if
    they defended their IP like the RIAA does?

    > > You can take what you need from the kernel to make your module work
    > > with it. Copyright does not cover what you need to make something
    > > work. Only patent does that. Copyright covers one choice out of
    > > millions of equally good ones.


    > But the intent of the license may influence whether you and your
    > customers are allowed to do anything that requires permission from the
    > copyright holders. At least over here.


    I don't see how the intent of the license can affect copyright law.
    I'm only talking about the *scope* of the license, and that is set by
    law, not by the license itself.

    DS

  10. Re: module license taints kernel.

    On Nov 26, 9:30 am, J de Boyne Pollard
    wrote:

    > DS> You will [not] find anything about
    > DS> "larger programs" or linking in copyright law.


    > You will, however, find a definition of an "adaptation" of a computer
    > program in section 21 of the U.K. Copyrights, Designs, and Patents Act
    > (as amended).


    I don't know enough about UK law to comment in detail, but on the
    surface, it appears that this has no effect. Linking is required in
    order to run a work distributed as source code, so linking would be
    permitted under that section and not be considered an adaptation.

    DS

  11. Re: module license taints kernel.

    David Schwartz writes:

    [...]

    > That's exactly what I'm arguing. That a linker is just like
    > tar+gzip.


    This statement has not become more true in the meantime. A linker is
    not an archiver because it does not create archive files. An archiver
    is not a linker because it does not create combined executables.

  12. Re: module license taints kernel.


    Rainer Weikusat wrote:

    > David Schwartz writes:


    > > That's exactly what I'm arguing. That a linker is just like
    > > tar+gzip.


    > This statement has not become more true in the meantime. A linker is
    > not an archiver because it does not create archive files. An archiver
    > is not a linker because it does not create combined executables.


    You can claim to have refuted any argument of the type "X is just like
    Y" by showing that there is some difference between X and Y. However,
    to have actually refuted it, you have to show that the difference
    *matters* in the context.

    Both linkers and archivers "mechanically" combine two works without
    any creativity. The result is the same as the input -- the two
    original works aggregated.

    For copyright purposes, the distinction is creative combination that
    can create a new derivative work. Neither linkers nor archivers can do
    this. For copyright purposes, they are the same process. They both
    combine the works in a mechanical way driven purely by functional
    requirements.

    DS

  13. Re: module license taints kernel.

    David Schwartz writes:
    > Rainer Weikusat wrote:
    >> David Schwartz writes:
    >> > That's exactly what I'm arguing. That a linker is just like
    >> > tar+gzip.

    >
    >> This statement has not become more true in the meantime. A linker is
    >> not an archiver because it does not create archive files. An archiver
    >> is not a linker because it does not create combined executables.

    >
    > You can claim to have refuted any argument of the type "X is just like
    > Y" by showing that there is some difference between X and Y.


    To the contrary, you try to make an argument of type 'X is just like
    Y' by showing that there is a superficial similarity between the two.
    Something like 'if we generously ignore the differences, the topics
    are actually fairly similar'. Quel surprise.

    > However,to have actually refuted it, you have to show that the
    > difference *matters* in the context.
    >
    > Both linkers and archivers "mechanically" combine two works without
    > any creativity. The result is the same as the input -- the two
    > original works aggregated.


    This sentence is in itself nonsensical, because an 'aggregation of two
    things' is obviously different from 'two separate things'. If it
    wasn't, why would a program be needed to create it?

    > For copyright purposes, the distinction is creative combination that
    > can create a new derivative work. Neither linkers nor archivers can do
    > this. For copyright purposes, they are the same process.


    This is as undisputed as 'the sun rises in the early morning' and as
    relevant 'for copyright purposes' (which you yourself
    state). Consequently, this perspective can be dropped entirely from
    the discussions.


  14. Re: module license taints kernel.

    On Nov 27, 10:59 am, Rainer Weikusat wrote:

    > > You can claim to have refuted any argument of the type "X is just like
    > > Y" by showing that there is some difference between X and Y.


    > To the contrary, you try to make an argument of type 'X is just like
    > Y' by showing that there is a superficial similarity between the two.
    > Something like 'if we generously ignore the differences, the topics
    > are actually fairly similar'. Quel surprise.


    I believe I did just that. Both linking and archiving are mechanical
    combinations of the two works for purely functional purposes. Both
    produce a final output that provide combined bits of the two input
    works. Neither creates a new work and neither requires any creativity.
    For copyright purposes, there is no significant difference at all.

    > > Both linkers and archivers "mechanically" combine two works without
    > > any creativity. The result is the same as the input -- the two
    > > original works aggregated.


    > This sentence is in itself nonsensical, because an 'aggregation of two
    > things' is obviously different from 'two separate things'. If it
    > wasn't, why would a program be needed to create it?


    Again, you have to show why the difference matters in context. Of
    course there's a difference literally speaking. Even two apples have
    to be in different places.

    For copyright purposes, it's just like putting two DVDs in the same
    box. The output is the same as the input -- the two original works.

    > > For copyright purposes, the distinction is creative combination that
    > > can create a new derivative work. Neither linkers nor archivers can do
    > > this. For copyright purposes, they are the same process.


    > This is as undisputed as 'the sun rises in the early morning' and as
    > relevant 'for copyright purposes' (which you yourself
    > state). Consequently, this perspective can be dropped entirely from
    > the discussions.


    Then what are we arguing about? If we both agree that for copyright
    purposes linking and archiving are the same, then we should be able to
    agree that neither creates a derivative work and neither extends
    copyright protection of the "input" works to the "output work" because
    there is no "output work" for copyright purposes.

    DS

  15. Re: module license taints kernel.

    On Tue, 27 Nov 2007 16:38:32 -0800 (PST) David Schwartz wrote:

    | Then what are we arguing about? If we both agree that for copyright
    | purposes linking and archiving are the same, then we should be able to
    | agree that neither creates a derivative work and neither extends
    | copyright protection of the "input" works to the "output work" because
    | there is no "output work" for copyright purposes.

    I what is in RAM what you are arguing about as being a derived work?
    Or is it a _copy_ of that RAM contents (such as dumping the RAM out to
    a favorite P2P repository)?

    I think we are getting down into the semantics of whether the copying
    _into_ RAM of the separate works is somehow different that the copying
    out _from_ RAM of a combined/derived/whatever work. But if we are not
    even copying out from the RAM, what are you guys even arguing your own
    agreements about?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-11-27-2330@ipal.net |
    |------------------------------------/-------------------------------------|

  16. Re: module license taints kernel.

    On Nov 27, 9:36 pm, phil-news-nos...@ipal.net wrote:

    > I what is in RAM what you are arguing about as being a derived work?
    > Or is it a _copy_ of that RAM contents (such as dumping the RAM out to
    > a favorite P2P repository)?


    I don't think either of us are arguing about "works" that are not
    fixed in a semi-permanent medium.

    > I think we are getting down into the semantics of whether the copying
    > _into_ RAM of the separate works is somehow different that the copying
    > out _from_ RAM of a combined/derived/whatever work. But if we are not
    > even copying out from the RAM, what are you guys even arguing your own
    > agreements about?


    I'm really only trying to make two points here:

    1) Linking is mere aggregation, just like archiving. They are both
    mechanical, functional processes that don't create a work. They are
    both purely dominated by functional considerations and are not
    creative. The opposite of mere aggregation is creatively-selective
    combination, which does produce a new work and does extend the
    expression of the input work(s).

    2) The functionality or functional intention of a work does not
    constitute an argument for expanding the scope of copyright. If
    anything, it reduces it. You can take just what you reasonably need to
    accomplish a particular function without taking any protectable
    expression. Only things not mandated by functional concerns can be
    expressive.

    DS

  17. Re: module license taints kernel.

    David Schwartz writes:

    > On Nov 26, 11:24 am, Lajos Parkatti ISES
    > wrote:
    >
    >> > In any event, the GPL grants you the right to copy and distribute the
    >> > original works. For copyright purposes, the result of linking is the
    >> > original works.

    >
    >> It grants you those rights, given that you obey the GPL. Not otherwise.


    > 1) You are confusing *who* needs to comply with the GPL. If you
    > distribute and copy a GPL'd work and I get a copy, that doesn't mean
    > that *I* need to comply with the GPL, it only means you do.


    Correct. But if some entity wants to distribute the GPL:ed kernel,
    they get the right to do so by obeying the license. You can perhaps
    trick your way through this by using third parties, if you are careful.

    > 2) You can't use a license to create copyright violation claims based
    > on violation of that license. In other words, you can't use a license
    > to make failure to release source code a copyright violation.


    Not directly. But you can sue somebody for the act of copying or
    distributing your work without permission. Then the one sued has to
    show that they indeed had permission. At least this is how the GPL is
    intended to work. If you don't like the GPL, don't distribute GPL-ware.

    >> You may distribute your non-derived work as you please, but you may
    >> not distribute the GPL:ed program together with it, if they form a
    >> "whole", i.e. if they _combined_ are a derivative work. In the
    >> aggregate you surely use creative expression from the original work.

    >
    > Clearly they are not if they are combined by a linker. A linker can't
    > create a new work, so it can't create a derivative work where there
    > wasn't one before.


    So there are at least three things to worry about:

    * does the module itself use enough of the creative expression of the
    kernel and does it use it in such a way that the result is a
    derivative work (this is not the case where the module is only
    somewhat modified to work with linux, otherwise it might be)

    * does the combination of the module and the kernel, and anything else
    involved, constitute a derivative work

    * are you copying or distributing the kernel, in which case you are
    bound by the GPL even when your work is not a derivative work in
    the copyright sense (this is important if the GPL restricts acts
    that are not covered by copyright law)

    I am not going to argue where to draw the lines, that is in most cases
    up to the courts.

    >> You seem to argue that even the running kernel is a "mere
    >> aggregation" of independent works. That sounds crazy.

    >
    > That's exactly what I'm arguing.


    OK, I leave it to the courts. There is of course also creative
    processes all over the place (somebody decides to link things in a
    certain way and things are combined in clever ways).

    >> > Right, except no copying or distributing is needed. I can download 100
    >> > copies of the Linux kernel from kernel.org, and I can put them on CD
    >> > and give them to 100 of my friends without either copying or
    >> > distributing the kernel, legally speaking.

    >
    >> Maybe. But then that kernel _is_ tainted. It cannot be distributed by
    >> folks downstream either.

    >
    > Nonsense. You have serious misunderstandings about how the GPL works.
    > Please read section 6 *very* carefully. People who redistribute
    > modified or unmodified GPL and BSD licensed works *NEVER* relicense
    > those works. The licenses always flow from the original author(s) to
    > the final recipients.


    Section 6 is irrelevant. You argue that you do not have to obey the GPL
    because you are not going to copy or redistribute the kernel. You do
    this by using a third party to do the copying.

    The poor folks downstream, who _do_ want to distribute the same thing
    _are_ bound by the GPL. If you had to resort to third parties to
    distribute your module alongside the kernel, so must they. I call such
    a kernel tainted. They do have the licence to distribute the kernel
    without your module, but that was not the thing under discussion.

    >> And I think you _are_ making copies already by downloading the program
    >> from kernel.org (at least that is the case legally where I live).


    > Nope. One copy flows over the network, is converted to the copy on
    > your disk, and that's that. One copy is all there is. The person who
    > sends it to you may arguably be copying (one copy on the disk, one on
    > the network, neither goes away since the recipient can make the
    > network copy persistent).


    So it is the person who put the kernel on ftp that is doing the
    copying, not the person typing "get"? Quite weird way to look at it!

    > You don't need to agree to the GPL to receive and use a GPL'd work.
    > The GPL is not a shrink-wrap agreement or EULA.


    Copying your copy of the kernel to a CD alongside your module is also
    copying (even if you delete the original), at least over here. As I
    said earlier, you could perhaps make it by using third parties to do
    the copying, but in some jurisdictions the court may look at what the
    intention was and who the principal agent was, not only at how it was
    done technically. So you need to be careful and know every legislation
    involved.

    >> > This is a case where Static Controls copied and distributed an entire
    >> > piece of software made by Lexmark. Lexmark sued them for DMCA and


    >> I am not familiar with your local legislation, so studying the case
    >> would be quite much work. And local case law isn't very important, as


    > The points I'm making are not minor legal technicalities, they are
    > fundamental things about how copyright works.


    Yes, your points are. But I have tried to read some law cases from the
    USA and it is not easy. You do not even provide a link to the case.
    If the reasoning really is obvious and general enough to make your
    point, then it certainly is interesting. I would still need a link to
    the relevant sections of the documents (and the documents themselves).
    Also, as both parties did go to court, the lawyers of Lexmark thought
    they could win. That probably means they still could win a similar case
    in some other legislation.

    >> we talk about an international product. I think however, that handling
    >> copies of a GPL product in a way that obviously isn't meant to be
    >> allowed by the license, is something that would require lawyers in every
    >> legislation where the product is going to be distr^H^H^H^H^sold. It
    >> may also give you more badwill than you want to have.


    > As for badwill, quite the opposite, the badwill results from people
    > who try to restrict what other people can do with what is theirs,
    > not from people who exercise the freedoms they have.


    With what is theirs because they were given it! Under certain obligations!
    So FSF gives me Emacs, and then I cry wolf because they are trying to
    restrict my "freedom" to sell a closed source modification. I think that
    is ridiculous. The FSF does not try to hide in small print on what terms
    you get their software. (Linux is not made by FSF, but I think they can
    represent what this discussion mainly is about)

    If you do not like the GPL and the spirit of it, just don't use such
    software, at least not in your own products. There are alternatives,
    BSD should fit if you want more freedom than the GPL gives you.

    > Wouldn't the free software movement be a bunch of crazy hypocrites if
    > they defended their IP like the RIAA does?


    Maybe. But they are _not_ defending their "IP" like the RIAA does.
    They use quite ordinary copyright law and a license that is more
    liberal and clear than the license of any (other) commercial product I
    have seen. They ask companies that break the license to cease doing
    so and might even go to court if that is needed. Your freedoms are not
    threatened by the existence of the FSF or the free software movement
    in general.

    You seem to suggest that they just should turn the other cheek and
    abandon anything that has been their motivations. Or that they should
    act as if choosing the GPL was a mistake and the intention was BSD.

    [1] The word is on FSF's list of words to avoid, so I wouldn't use it here.

    >> But the intent of the license may influence whether you and your
    >> customers are allowed to do anything that requires permission from the
    >> copyright holders. At least over here.

    >
    > I don't see how the intent of the license can affect copyright law.


    It doesn't. But if you need permission from the copyright owners
    under copyright law, then you get that permission through the GPL.
    When deciding whether or not you have fulfilled your obligations under
    the GPL, the court will also look at the intent of that license, as
    long as that intent is obvious from careful reading (the licensee
    cannot be supposed to understand an intent that isn't).

    If it is clear that you are distributing the software in a way that
    was not intended to be allowed, then the court may decide that it
    indeed was not allowed, and you have distributed software without
    permission, which is a case for copyright law (there may also be
    cases regarded as breaching a contract, but that shouldn't be the
    obvious ones).

    > I'm only talking about the *scope* of the license, and that is set by
    > law, not by the license itself.


    --
    Lajos Parkatti

  18. module license taints kernel.

    LP> And I think you _are_ making copies already by
    LPI> downloading the program from kernel.org (at
    LPI> least that is the case legally where I live).

    DS> Nope. One copy flows over the network, is converted
    DS> to the copy on your disk, and that's that. One copy is
    DS> all there is. The person who sends it to you may
    DS> arguably be copying (one copy on the disk, one on the
    DS> network, neither goes away since the recipient can
    DS> make the network copy persistent).

    LPI> So it is the person who put the kernel on ftp that
    LPI> is doing the copying, not the person typing "get"?
    LPI> Quite weird way to look at it!

    You are creating straw men. That is not what M. Schwartz wrote at
    all.

    To understand what M. Schwartz _actually wrote_, read cr.yp.to/rights.html>.

    LPI> If you do not like the GPL, then [...]

    Again, you are creating straw men. M. Schwartz has expressed no such
    dislike.

  19. Re: module license taints kernel.

    On Nov 30, 2:39 am, Lajos Parkatti ISES
    wrote:

    > > 2) You can't use a license to create copyright violation claims based
    > > on violation of that license. In other words, you can't use a license
    > > to make failure to release source code a copyright violation.


    > Not directly. But you can sue somebody for the act of copying or
    > distributing your work without permission. Then the one sued has to
    > show that they indeed had permission. At least this is how the GPL is
    > intended to work.


    Right, and the issue will be did you or did you not comply with the
    GPL. This is a contract issue, not a copyright issue.

    Again, you cannot use a license to turn actions that do not violate
    copyright (such as failing to distribute source code) into copyright
    violations. Copyright violations can only be created by statute.
    License violations are not copyright violations (unless they exceed
    the scope of the license according to copyright law).

    > If you don't like the GPL, don't distribute GPL-ware.


    And if you don't like EULAs, don't buy software that has them. And if
    you don't like your government, move. Don't fix things. Don't exercise
    your rights.

    It's not that I don't like the GPL. I don't like misunderstandings of
    the GPL. I also don't like people who claim to be friends of free
    software who actually argue for huge expansions of rights under
    copyright.

    > > Clearly they are not if they are combined by a linker. A linker can't
    > > create a new work, so it can't create a derivative work where there
    > > wasn't one before.


    > So there are at least three things to worry about:
    >
    > * does the module itself use enough of the creative expression of the
    > kernel and does it use it in such a way that the result is a
    > derivative work (this is not the case where the module is only
    > somewhat modified to work with linux, otherwise it might be)


    Yes, that's one issue. Note that by "creative expression of the
    kernel" you mean beyond what is reasonably necessary to accomplish the
    module's function.

    > * does the combination of the module and the kernel, and anything else
    > involved, constitute a derivative work


    It cannot unless the module itself was a derivative work. The
    "combination" cannot ever create a new work, so if there was no
    derivative work before combination, there cannot be one after. (This
    is assuming the combination function is purely functional, which it
    should be in all cases I can think of.)

    > * are you copying or distributing the kernel, in which case you are
    > bound by the GPL even when your work is not a derivative work in
    > the copyright sense (this is important if the GPL restricts acts
    > that are not covered by copyright law)


    Right, but this means "copying or distributing" as defined in
    copyright law, not as defined in the GPL or in the common sense
    meaning of those terms. And, again, this would only mean you had to
    provide the source code to the kernel itself, not to your module
    because they're not derivative works. (Assuming they're not.)

    > I am not going to argue where to draw the lines, that is in most cases
    > up to the courts.


    Right, there are several lines here that are very tricky to draw. The
    hardest ones is whether large literal takings can be justified as
    purely functional.

    > >> You seem to argue that even the running kernel is a "mere
    > >> aggregation" of independent works. That sounds crazy.


    > > That's exactly what I'm arguing.


    > OK, I leave it to the courts. There is of course also creative
    > processes all over the place (somebody decides to link things in a
    > certain way and things are combined in clever ways).


    True, but so long as you link it in the minimal way reasonably needed
    to produce the functional result, there's no issue. I think you'll
    find courts will treat this much the same as coloring in a coloring
    book.

    > > Nonsense. You have serious misunderstandings about how the GPL works.
    > > Please read section 6 *very* carefully. People who redistribute
    > > modified or unmodified GPL and BSD licensed works *NEVER* relicense
    > > those works. The licenses always flow from the original author(s) to
    > > the final recipients.


    > Section 6 is irrelevant. You argue that you do not have to obey the GPL
    > because you are not going to copy or redistribute the kernel. You do
    > this by using a third party to do the copying.


    Section 6 explains copyright law, and does a pretty good job of it.
    All GPL-like licenses operate by giving every lawful recipient of the
    work a license from each individual author. None of them do or can
    support re-licensing. The GPL is not irrelevant because it has no
    limitations on who can take advantage of it.

    You don't have to obey the GPL to have the GPL available to you. You
    just have to not violate it.

    > The poor folks downstream, who _do_ want to distribute the same thing
    > _are_ bound by the GPL. If you had to resort to third parties to
    > distribute your module alongside the kernel, so must they. I call such
    > a kernel tainted. They do have the licence to distribute the kernel
    > without your module, but that was not the thing under discussion.


    That would make a lot of things tainted, including my WRT56GS running
    OpenWRT since it has a proprietary Broadcom driver. Heck, that would
    make an OpenWRT CD tainted.

    If you want to call any distribution that includes non-GPL'd elements
    "tainted", then fine. But remember, we started out with the module not
    being GPL'd anyway. So to argue that the result is not GPL'd should
    just get a big "duh". Our whole starting goal was to restrict
    distribution. (At least of the source code.)

    > > Nope. One copy flows over the network, is converted to the copy on
    > > your disk, and that's that. One copy is all there is. The person who
    > > sends it to you may arguably be copying (one copy on the disk, one on
    > > the network, neither goes away since the recipient can make the
    > > network copy persistent).


    > So it is the person who put the kernel on ftp that is doing the
    > copying, not the person typing "get"? Quite weird way to look at it!


    If the person downloading the program is doing the copying, then the
    GPL cannot possibly apply to them at that point. They may not have
    even had a chance to read it, much less agree to it. They may not even
    know the work is GPL'd.

    If the GPL applied that way, every site that offered GPL'd works for
    electronic distirbution would need some kind of GPL click-through or
    notification/agreement.

    Do you violate copyright when you go to a web page that has a
    copyrighted image?

    > >> > This is a case where Static Controls copied and distributed an
    > >> >entire
    > >> > piece of software made by Lexmark. Lexmark sued them for DMCA and
    > >> I am not familiar with your local legislation, so studying the case
    > >> would be quite much work. And local case law isn't very important, as


    > > The points I'm making are not minor legal technicalities, they are
    > > fundamental things about how copyright works.


    > Yes, your points are. But I have tried to read some law cases from the
    > USA and it is not easy. You do not even provide a link to the case.


    Google should provide it quickly, it's a commonly-cited and commonly-
    read case.

    > If the reasoning really is obvious and general enough to make your
    > point, then it certainly is interesting. I would still need a link to
    > the relevant sections of the documents (and the documents themselves).
    > Also, as both parties did go to court, the lawyers of Lexmark thought
    > they could win. That probably means they still could win a similar case
    > in some other legislation.


    That was largely because their DMCA arguments were untested at the
    time. There were other issues in that same case that Lexmark felt were
    strong, I don't think Lexmark expected their direct copyright
    arguments to work.

    This was a kind of extreme case though. An entire work was taken,
    literally byte for byte, and justified on functional grounds.

    > With what is theirs because they were given it! Under certain
    > obligations!
    > So FSF gives me Emacs, and then I cry wolf because they are trying to
    > restrict my "freedom" to sell a closed source modification. I think that
    > is ridiculous. The FSF does not try to hide in small print on what terms
    > you get their software. (Linux is not made by FSF, but I think they can
    > represent what this discussion mainly is about)
    >
    > If you do not like the GPL and the spirit of it, just don't use such
    > software, at least not in your own products. There are alternatives,
    > BSD should fit if you want more freedom than the GPL gives you.


    This is a perfectly fine thing for an advocate of extreme rights for
    authors and closed-source software to say. It's a horrible thing for
    anyone who even pretends to care about free software to say.

    If you don't like the rights the creator chooses to give you, do
    without it. The law should let the creator set whatever terms he wants
    and you should feel honor-bound to obey them.

    Is that really what you believe?

    > > Wouldn't the free software movement be a bunch of crazy hypocrites if
    > > they defended their IP like the RIAA does?


    > Maybe. But they are _not_ defending their "IP" like the RIAA does.


    They are. Really.

    > They use quite ordinary copyright law and a license that is more
    > liberal and clear than the license of any (other) commercial product I
    > have seen.


    But they don't. That's what this whole thread is about.

    > They ask companies that break the license to cease doing
    > so and might even go to court if that is needed. Your freedoms are not
    > threatened by the existence of the FSF or the free software movement
    > in general.


    They are if the free software movement argues for expansions to
    author's copyright rights. For example, the free software movement
    could get a law passed that declared that linking created a derivative
    work. That would reduce *everyone's* rights to all copyrighted works.
    That threatens my freedoms.

    > You seem to suggest that they just should turn the other cheek and
    > abandon anything that has been their motivations. Or that they should
    > act as if choosing the GPL was a mistake and the intention was BSD.


    No, that's not what I'm saying. I'm saying they should argue for more
    freedoms, not fewer.

    > [1] The word is on FSF's list of words to avoid, so I wouldn't use it
    > here.


    Now the FSF is going to tell me what concepts I can think about and
    talk about? The FSF's argument about this is absurd and I reject it
    utterly. (Others contractual or legal obligations to your *are*
    property. That's why your bank can sell your mortgage to someone
    else.)

    > > I don't see how the intent of the license can affect copyright law.


    > It doesn't. But if you need permission from the copyright owners
    > under copyright law, then you get that permission through the GPL.


    Right, but all that I've been talking about is the scope of copyright
    law. The GPL's intent can't matter to its scope.

    If you want to argue that I have to comply with the GPL to do X, then
    you must argue that X is not fair use. So, if I have to comply with
    the GPL to compile a GPL'd library and link it to my own program, then
    that cannot be part of fair use.

    > When deciding whether or not you have fulfilled your obligations under
    > the GPL, the court will also look at the intent of that license, as
    > long as that intent is obvious from careful reading (the licensee
    > cannot be supposed to understand an intent that isn't).


    Right. But I don't think I've said word one about what it takes to
    comply with the GPL. At least, no in this thread.

    > If it is clear that you are distributing the software in a way that
    > was not intended to be allowed, then the court may decide that it
    > indeed was not allowed, and you have distributed software without
    > permission, which is a case for copyright law (there may also be
    > cases regarded as breaching a contract, but that shouldn't be the
    > obvious ones).


    It can't be. You can't violate copyright law unless you exceed the
    scope of the license under copyright law. Creating and distributing
    derivative works is within the scope of the license.

    > > I'm only talking about the *scope* of the license, and that is set by
    > > law, not by the license itself.


    Do you see the implications of that?

    DS

  20. module license taints kernel.

    DS> You will [not] find anything about
    DS> "larger programs" or linking in copyright law.

    JdeBP> You will, however, find a definition of an
    JdeBP> "adaptation" of a computer program in
    JdeBP> section 21 of the U.K. Copyrights,
    JdeBP> Designs, and Patents Act (as amended).

    DS> I don't know enough about UK law to comment
    DS> in detail, but on the surface, it appears that this
    DS> has no effect. Linking is required in order to run
    DS> a work distributed as source code, so linking
    DS> would be permitted under that section and not
    DS> be considered an adaptation.

    No. What is required in order to run a work distributed as source
    code is _compiliation_, from source code to machine code. This falls
    within the CDPA's definition of "translation" for computer programs
    (right there in the very same section of the Act), which in turn is
    considered to be "adaptation" of that work. Whether linking, in order
    to adapt the object code to operate in conjunction with other object
    code, is further adaptation is not spelled out by the Act, but it
    should be clear that there's a case to be made that it is.

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast