module license taints kernel. - Linux

This is a discussion on module license taints kernel. - Linux ; Hi All I have written kernel module (File System Driver). When i tried to insert kernel Module i am getting "module license taints kernel." Since i am NOT specifying 'GPL'. So it is giving. I want to know what happens ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 41

Thread: module license taints kernel.

  1. module license taints kernel.

    Hi All

    I have written kernel module (File System Driver).

    When i tried to insert kernel Module i am getting

    "module license taints kernel."

    Since i am NOT specifying 'GPL'. So it is giving.

    I want to know what happens if i use NON-VERSION under LInux or can I
    use. or If i want to use NON-GPL what conditions i have to meet.

    Thanks & Regards
    Guru

  2. Re: module license taints kernel.

    On Wed, 14 Nov 2007 21:06:07 -0800 (PST), guru wrote:

    > I have written kernel module (File System Driver).
    >
    > When i tried to insert kernel Module i am getting
    >
    > "module license taints kernel."
    >
    > Since i am NOT specifying 'GPL'. So it is giving.
    >
    > I want to know what happens if i use NON-VERSION under LInux or can I
    > use. or If i want to use NON-GPL what conditions i have to meet.


    You are allowed to *use* a "tainted" kernel; but *distributing* it would be a
    violation of the license and illegal.

    http://www.gnu.org/copyleft/gpl.html
    http://en.wikipedia.org/wiki/GNU_General_Public_License

    Bob T.

  3. Re: module license taints kernel.

    Bob Tennent wrote:

    > You are allowed to *use* a "tainted" kernel; but *distributing* it would be a
    > violation of the license and illegal.


    Not necessarily. It may depend if the "mere aggregation" clause is
    applicable.

    The proper answer is to consult a lawyer who is familiar with the
    appropriate copyright law for the country in question.

    Chris

  4. Re: module license taints kernel.

    On Thu, 15 Nov 2007 10:57:32 -0600, Chris Friesen wrote:
    > Bob Tennent wrote:
    >
    >> You are allowed to *use* a "tainted" kernel; but *distributing* it would be a
    >> violation of the license and illegal.

    >
    > Not necessarily. It may depend if the "mere aggregation" clause is
    > applicable.


    The tainted kernel incorporating the module is surely not an aggregate:

    A compilation of a covered work with other separate and independent
    works, which are not by their nature extensions of the covered work, and
    which are not combined with it such as to form a larger program, in or
    on a volume of a storage or distribution medium, is called an
    "aggregate" ...

    > The proper answer is to consult a lawyer who is familiar with the
    > appropriate copyright law for the country in question.


    Consulting a lawyer will cost you and, when the answer is perfectly
    evident, is unlikely to be useful.

    As should be evident, IANAL.

  5. Re: module license taints kernel.

    On Nov 15, 9:21 am, Bob Tennent wrote:

    > The tainted kernel incorporating the module is surely not an aggregate:


    Yes, it is.

    > A compilation of a covered work with other separate and independent
    > works, which are not by their nature extensions of the covered work, and
    > which are not combined with it such as to form a larger program, in or
    > on a volume of a storage or distribution medium, is called an
    > "aggregate" ...


    I'm not sure where you got that from, but it's wrong. An "aggregate"
    is any combination made by automated means, as opposed to creative
    means, with a few narrow exceptions specified by copyright law. (Such
    as translation, since it was probably assumed at the time the law was
    made that translation had to be creative.)

    So compilers, linkers, and archivers make aggregates of their input
    works. Human beings who combine things creatively can make new works
    that are not merely aggregates of the input.

    If you feed a bunch of input works into anything that cannot add
    creative input, it cannot create a new work. All it can do is
    aggregate the inputs. Under copyright law, it takes creative input to
    create a new work, even a new derivative work.

    DS

  6. Re: module license taints kernel.

    On Thu, 15 Nov 2007 13:37:28 -0800 (PST), David Schwartz wrote:
    > On Nov 15, 9:21 am, Bob Tennent wrote:
    >
    >> The tainted kernel incorporating the module is surely not an aggregate:

    >
    > Yes, it is.
    >
    >> A compilation of a covered work with other separate and independent
    >> works, which are not by their nature extensions of the covered work, and
    >> which are not combined with it such as to form a larger program, in or
    >> on a volume of a storage or distribution medium, is called an
    >> "aggregate" ...

    >
    > I'm not sure where you got that from, but it's wrong.


    It's a definition taken from the GPL. By "wrong" I presume you mean
    that it differs from what is conventional in copyright law. I don't
    think it's improper to re-define a conventional term for some specific
    purpose. The GPL grants rights that are otherwise denied by copyright
    law. By my reading of the GPL, a tainted kernel is not a GPL-defined
    aggregate and hence the "mere aggregate" provision of the GPL allowing
    distribution doesn't apply. The issue isn't whether the tainted kernel
    might be a derivative work under copyright law, but whether distribution
    is allowed by the GPL.

    Bob T.

    > An "aggregate"
    > is any combination made by automated means, as opposed to creative
    > means, with a few narrow exceptions specified by copyright law. (Such
    > as translation, since it was probably assumed at the time the law was
    > made that translation had to be creative.)
    >
    > So compilers, linkers, and archivers make aggregates of their input
    > works. Human beings who combine things creatively can make new works
    > that are not merely aggregates of the input.
    >
    > If you feed a bunch of input works into anything that cannot add
    > creative input, it cannot create a new work. All it can do is
    > aggregate the inputs. Under copyright law, it takes creative input to
    > create a new work, even a new derivative work.
    >
    > DS


  7. Re: module license taints kernel.

    On 16 Nov 2007 00:51:14 GMT, Bob Tennent wrote:

    > By my reading of the GPL, a tainted kernel is not a GPL-defined
    > aggregate and hence the "mere aggregate" provision of the GPL allowing
    > distribution doesn't apply.


    Further explanation from the GPL FAQ:

    What is the difference between "mere aggregation" and "combining two
    modules into one program"?

    Mere aggregation of two programs means putting them side by side on
    the same CD-ROM or hard disk. We use this term in the case where they
    are separate programs, not parts of a single program. In this case, if
    one of the programs is covered by the GPL, it has no effect on the other
    program.

    Combining two modules means connecting them together so that they
    form a single larger program. If either part is covered by the GPL, the
    whole combination must also be released under the GPL--if you can't, or
    won't, do that, you may not combine them.

    What constitutes combining two parts into one program? This is a
    legal question, which ultimately judges will decide. We believe that a
    proper criterion depends both on the mechanism of communication (exec,
    pipes, rpc, function calls within a shared address space, etc.) and the
    semantics of the communication (what kinds of information are
    interchanged).

    If the modules are included in the same executable file, they are
    definitely combined in one program. If modules are designed to run
    linked together in a shared address space, that almost surely means
    combining them into one program.



  8. Re: module license taints kernel.

    David Schwartz writes:
    > On Nov 15, 9:21 am, Bob Tennent wrote:
    >> The tainted kernel incorporating the module is surely not an aggregate:


    [...]

    >> A compilation of a covered work with other separate and independent
    >> works, which are not by their nature extensions of the covered work, and
    >> which are not combined with it such as to form a larger program, in or
    >> on a volume of a storage or distribution medium, is called an
    >> "aggregate" ...

    >
    > I'm not sure where you got that from, but it's wrong. An "aggregate"
    > is any combination made by automated means, as opposed to creative
    > means,


    Exactly. And developing something original such that it can function
    as part of some other original work is not 'automated' but
    'creative'. The Linux exception for binary modules only applies to
    code not originally developed to become part of the Linux kernel,
    using some kind of OS-dependent glue layer to interface with it.

    [...]

    > So compilers, linkers, and archivers make aggregates of their input
    > works.


    Archivers have no place in here (except maybe as a blind). Neither
    have compilers. But a linker, even if it is only a runtime linker,
    does not create 'archives', but combinates different binaries in a way
    enabling them to function as a whole, providing some functionality
    none of the parts could provide on its own. For this to be possible,
    the parts have to be created specifically to make it possible, which
    necessitates a creative act.

  9. Re: module license taints kernel.

    On Nov 15, 4:51 pm, Bob Tennent wrote:

    > It's a definition taken from the GPL. By "wrong" I presume you mean
    > that it differs from what is conventional in copyright law. I don't
    > think it's improper to re-define a conventional term for some specific
    > purpose. The GPL grants rights that are otherwise denied by copyright
    > law. By my reading of the GPL, a tainted kernel is not a GPL-defined
    > aggregate and hence the "mere aggregate" provision of the GPL allowing
    > distribution doesn't apply. The issue isn't whether the tainted kernel
    > might be a derivative work under copyright law, but whether distribution
    > is allowed by the GPL.


    I didn't mean the excerpt is wrong, I meant that to use the excerpt
    the way you did is wrong. The GPL cannot set its own scope. Whether
    the GPL's rules apply is a question of scope.

    If the GPL said, "this license applies to every work every written by
    anyone who has ever seen a work covered by this license", that
    obviously would not mean that this was actually *true*.

    Several parts of the GPL attempt to explain the scope of the GPL, but
    they are not the final authority on the scope of the GPL. The GPL
    cannot affect mere aggregates because of principles of copyright law.
    If you buy a legal DVD copy of The Lion King, you don't need anyone's
    permission to put it in the same box as a copy of The Phantom Menace.
    It wouldn't matter what the licenses on the two DVDs said, that's mere
    aggregation.

    The GPL knows that it cannot "taint" a work just because it's
    aggregated with a covered work and tries to explain what "aggregation"
    means. It does an okay job.

    Ask yourself, is a tar+gzip "mere aggregation"? Bits of one work are
    removed and replaced with references to the other work.

    DS

  10. Re: module license taints kernel.

    On Nov 16, 2:01 am, Rainer Weikusat wrote:

    > > So compilers, linkers, and archivers make aggregates of their input
    > > works.


    > Archivers have no place in here (except maybe as a blind).


    Not true. Tar+gzip replaces bits of one work with references to the
    other.

    > Neither
    > have compilers. But a linker, even if it is only a runtime linker,
    > does not create 'archives', but combinates different binaries in a way
    > enabling them to function as a whole, providing some functionality
    > none of the parts could provide on its own.


    That doesn't matter. The combination is not creative. The linker
    cannot create a new work for copyright purposes, thus it cannot create
    a derivative work. (A "derivative work" is a form of new work, legally
    distinct from the original.)

    > For this to be possible,
    > the parts have to be created specifically to make it possible, which
    > necessitates a creative act.


    That's true, but irrelevant.

    Suppose you write a C program and I write a drop-in malloc
    replacement. It's true that in order for your library to be able to
    link to my drop-in malloc replacement, creative effort is required on
    the part of both of us. But that doesn't make either your C program
    nor my drop-in malloc replacement dependent on the other. In fact, you
    could develop your program and me my library with no communication or
    knowledge of each other whatsoever. The two works could be totally
    independent, but capable of being linked together and having new
    functionality when so linked -- functionality intended by neither of
    us.

    And when some third-party links them together, no new work is created.
    This must be so because no creative effort is needed to link them
    together.

    DS

  11. Re: module license taints kernel.

    On Fri, 16 Nov 2007 13:51:08 -0800 (PST), David Schwartz wrote:
    > On Nov 15, 4:51 pm, Bob Tennent wrote:
    >
    >> It's a definition taken from the GPL. By "wrong" I presume you mean
    >> that it differs from what is conventional in copyright law. I don't
    >> think it's improper to re-define a conventional term for some specific
    >> purpose. The GPL grants rights that are otherwise denied by copyright
    >> law. By my reading of the GPL, a tainted kernel is not a GPL-defined
    >> aggregate and hence the "mere aggregate" provision of the GPL allowing
    >> distribution doesn't apply. The issue isn't whether the tainted kernel
    >> might be a derivative work under copyright law, but whether distribution
    >> is allowed by the GPL.

    >
    > I didn't mean the excerpt is wrong, I meant that to use the excerpt
    > the way you did is wrong. The GPL cannot set its own scope. Whether
    > the GPL's rules apply is a question of scope.
    >
    > If the GPL said, "this license applies to every work every written by
    > anyone who has ever seen a work covered by this license", that
    > obviously would not mean that this was actually *true*.
    >
    > Several parts of the GPL attempt to explain the scope of the GPL, but
    > they are not the final authority on the scope of the GPL. The GPL
    > cannot affect mere aggregates because of principles of copyright law.
    > If you buy a legal DVD copy of The Lion King, you don't need anyone's
    > permission to put it in the same box as a copy of The Phantom Menace.
    > It wouldn't matter what the licenses on the two DVDs said, that's mere
    > aggregation.


    It's not the act of aggregation that's covered or not. It's the act of
    *distributing* an aggregate that contains a GPLed work. The requirements
    of the GPL on distributors do *not* apply to the non-GPled components;
    that's why the "mere aggregation" clause was suggested by a previous
    poster. But a kernel linked with a non-GPLed module is not an aggregate
    as defined by the GPL. The GPL doesn't stop you doing it, but it doesn't
    allow distribution, which is completely within its scope, or rather the
    scope of the copyright owners.

    > Ask yourself, is a tar+gzip "mere aggregation"? Bits of one work are
    > removed and replaced with references to the other work.


    I'd say yes; tar+gzip doesn't produce "a larger program". Linking
    in a module does; very different.

    Bob T.

  12. Re: module license taints kernel.

    David Schwartz writes:
    > On Nov 16, 2:01 am, Rainer Weikusat wrote:
    >> > So compilers, linkers, and archivers make aggregates of their input
    >> > works.

    >
    >> Archivers have no place in here (except maybe as a blind).

    >
    > Not true. Tar+gzip replaces bits of one work with references to the
    > other.


    It is true, because it is the purpose of archivers to aggregate
    unrelated files together into one file in a way that enable
    dis-aggregating them again and nothing more.

    >> Neither have compilers. But a linker, even if it is only a runtime linker,
    >> does not create 'archives', but combinates different binaries in a way
    >> enabling them to function as a whole, providing some functionality
    >> none of the parts could provide on its own.

    >
    > That doesn't matter. The combination is not creative.


    That's why I wrote that the 'creative' part would be the one which
    enables two different files to be mechanically combinated in a way
    that they function as a whole. So, what really "doesn't matter" is
    your discussion of something different.

    >> For this to be possible, the parts have to be created specifically
    >> to make it possible, which necessitates a creative act.

    >
    > That's true, but irrelevant.
    >
    > Suppose you write a C program and I write a drop-in malloc
    > replacement. It's true that in order for your library to be able to
    > link to my drop-in malloc replacement, creative effort is required on
    > the part of both of us. But that doesn't make either your C program
    > nor my drop-in malloc replacement dependent on the other. In fact, you
    > could develop your program and me my library with no communication or
    > knowledge of each other whatsoever.


    This is a different case, because both components effectively interact
    according to an interface defined independently of both of them. And
    it is a different case which is not relevant for Linux kernel-modules,
    because this property does not exist there.

    Suppose I write a text and you remove its context to be able to create
    an easy contradiction, utilizing the changed meaning created by
    you. Did you now argue against an opinion which I held or did you just
    use some parts of the 'raw material' which was accidentally necessary
    to communicate said opinion to construct a better strawman?

    I strongly suggest that anybody having any doubts regarding that the
    factually correct answer is 'the latter' should take an introductory
    lecture in semantics. Quoting the Wikipedia-article on this:

    Each of a set of synonyms like redouter ('to dread'), craindre
    ('to fear'), avoir peur ('to be afraid') has its particular
    value only because they stand in contrast with one another. No
    word has a value that can be identified independently of what
    else is in its vicinity.
    (de Saussure)

    If I combined your indepedent malloc implementation with some GPL'ed
    code to create something which has a function of its own, utilizing
    both pieces of code as parts of them, I would have created a
    derivative work and would not be allowed to distribute it except if I
    was allowed to distribute this malloc replacement according to the
    terms of the GPL.

    [...]

    > And when some third-party links them together, no new work is created.
    > This must be so because no creative effort is needed to link them
    > together.


    A really bad (IMO) German rap band called 'The Fanastic Four' was IIRC
    sucessfully sued by J.J. Cale because they incorporated a part of one
    of his songs into one of them some time in the first half of the
    1990s. But the act of 'aggregating' two indepedent sounds onto some
    medium using a suitable recording device is certainly mechanical and
    the recording device cannot create anything on its own. If you were
    right, you would have proven that this didn't happen and, by
    extension, that HipHop is inherently uncreative in nature.

    While I would agree with that, some people might feel inclined to call
    this a prejudices of mine :->.

  13. Re: module license taints kernel.

    On Nov 16, 3:48 pm, Bob Tennent wrote:

    > It's not the act of aggregation that's covered or not. It's the act of
    > *distributing* an aggregate that contains a GPLed work.


    You can have it either of two ways:

    1) It's an aggregate, and the GPL does not require you to distribute
    the source code of the other works aggregated with the covered work.

    2) It's perhaps not an aggregate, and we have to decide if the GPL is
    in scope or not. Check copyright law, you will find no section that
    reserves to the copyright holder the right to control the distribution
    of works that are non-creatively derived from lawful copies.

    Neither way permits the GPL to cover works that are aggregated non-
    creatively.

    > The requirements
    > of the GPL on distributors do *not* apply to the non-GPled components;
    > that's why the "mere aggregation" clause was suggested by a previous
    > poster. But a kernel linked with a non-GPLed module is not an aggregate
    > as defined by the GPL. The GPL doesn't stop you doing it, but it doesn't
    > allow distribution, which is completely within its scope, or rather the
    > scope of the copyright owners.


    You have completely missed my point. If the question is whether the
    GPL *applies*, how the GPL defines things doesn't matter. The GPL does
    not get to set its own scope. I am saying the GPL does not *apply* to
    the work because the work is outside of the GPL's scope as defined by
    copyright law.

    > > Ask yourself, is a tar+gzip "mere aggregation"? Bits of one work are
    > > removed and replaced with references to the other work.


    > I'd say yes; tar+gzip doesn't produce "a larger program". Linking
    > in a module does; very different.


    These are interesting intuitions about how computers work, but have no
    effect whatsoever on copyright law. You will find anything about
    "larger programs" or linking in copyright law.

    Legally, only three things matter:

    1) Does the combination contain protectable components from the work?

    2) Is the combination mechanical or creative?

    3) Does the combination fall into one of the narrow exceptions (such
    as translation) specifically defined by copyright law.

    This is all that matters when you're trying to decide if the GPL can
    affect a work or not. The GPL can say what it *does* to a work, but
    not whether it *applies* to a work.

    None of these things differ between a linker and a tar+gzip. Both, for
    copyright purposes, simply produce the input works. (Possibly with
    protectable elements from the linker or archiver.) They are legally
    mere aggregators, no different from putting two DVDs in the same box.

    DS

  14. Re: module license taints kernel.

    On Nov 18, 2:52 am, Rainer Weikusat wrote:

    > That's why I wrote that the 'creative' part would be the one which
    > enables two different files to be mechanically combinated in a way
    > that they function as a whole. So, what really "doesn't matter" is
    > your discussion of something different.


    So you rescind your claim that linkers create derivative works? You
    have a new claim -- that a work fed into a linker might be a
    derivative work of some other work. Well, duh, of course it might.

    > > Suppose you write a C program and I write a drop-in malloc
    > > replacement. It's true that in order for your library to be able to
    > > link to my drop-in malloc replacement, creative effort is required on
    > > the part of both of us. But that doesn't make either your C program
    > > nor my drop-in malloc replacement dependent on the other. In fact, you
    > > could develop your program and me my library with no communication or
    > > knowledge of each other whatsoever.


    > This is a different case, because both components effectively interact
    > according to an interface defined independently of both of them. And
    > it is a different case which is not relevant for Linux kernel-modules,
    > because this property does not exist there.


    That's not why it's different. The reason it's different is because it
    is clear that neither work is a derivative of the other before they
    are linked.

    If they weren't before they were linked, they aren't after. It's that
    simple.

    > Suppose I write a text and you remove its context to be able to create
    > an easy contradiction, utilizing the changed meaning created by
    > you. Did you now argue against an opinion which I held or did you just
    > use some parts of the 'raw material' which was accidentally necessary
    > to communicate said opinion to construct a better strawman?


    I don't understand how this could possibly be relevant. What human
    beings do is nothing remotely like what linkers do. Of course when a
    human being combines two works, they might create a new work in the
    process, that's because human beings are creative. Linkers are not,
    so there is no question that they did not create a new work. If they
    could, they would be entitled to copyright on the work.

    > If I combined your indepedent malloc implementation with some GPL'ed
    > code to create something which has a function of its own, utilizing
    > both pieces of code as parts of them, I would have created a
    > derivative work and would not be allowed to distribute it except if I
    > was allowed to distribute this malloc replacement according to the
    > terms of the GPL.


    Yes, if you did so by a creative process. No, if you did so by an
    automated, non-creative process.

    > > And when some third-party links them together, no new work is created.
    > > This must be so because no creative effort is needed to link them
    > > together.


    > A really bad (IMO) German rap band called 'The Fanastic Four' was IIRC
    > sucessfully sued by J.J. Cale because they incorporated a part of one
    > of his songs into one of them some time in the first half of the
    > 1990s. But the act of 'aggregating' two indepedent sounds onto some
    > medium using a suitable recording device is certainly mechanical and
    > the recording device cannot create anything on its own. If you were
    > right, you would have proven that this didn't happen and, by
    > extension, that HipHop is inherently uncreative in nature.


    Right, because they did so creatively. They are human beings, they are
    not automated linkers. The question is whether linking can create a
    derivative work where one did not exist before.

    In any event, your example fails for another reason. Suppose I take
    Sting CDs and add some extra drum hits to them. Of course I can't copy
    them and sell them. This is true whether or not my CD contains
    sufficient new creative effort to be a new work. So this sheds no
    light whatsoever on the nature of the resultant work, which is what
    we're talking about.

    > While I would agree with that, some people might feel inclined to call
    > this a prejudices of mine :->.


    There is another legal question about how much creative effort is
    required before a new work results that entitles the person who
    applies that creative effort to copyright rights on the resultant
    work. It is definitely more than typing 'ld'.

    DS

  15. Re: module license taints kernel.

    David Schwartz writes:
    > On Nov 18, 2:52 am, Rainer Weikusat wrote:
    >> That's why I wrote that the 'creative' part would be the one which
    >> enables two different files to be mechanically combinated in a way
    >> that they function as a whole. So, what really "doesn't matter" is
    >> your discussion of something different.

    >
    > So you rescind your claim that linkers create derivative works?


    If have never claimed that linkers create derivative works.

    > You have a new claim -- that a work fed into a linker might be a
    > derivative work of some other work. Well, duh, of course it might.


    No. I still have the original claim, namely, that what is fed into the
    linker constitutes 'a work'.

    >> > Suppose you write a C program and I write a drop-in malloc
    >> > replacement. It's true that in order for your library to be able to
    >> > link to my drop-in malloc replacement, creative effort is required on
    >> > the part of both of us. But that doesn't make either your C program
    >> > nor my drop-in malloc replacement dependent on the other. In fact, you
    >> > could develop your program and me my library with no communication or
    >> > knowledge of each other whatsoever.

    >
    >> This is a different case, because both components effectively interact
    >> according to an interface defined independently of both of them. And
    >> it is a different case which is not relevant for Linux kernel-modules,
    >> because this property does not exist there.

    >
    > That's not why it's different.


    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.

    [...]

    >> If I combined your indepedent malloc implementation with some GPL'ed
    >> code to create something which has a function of its own, utilizing
    >> both pieces of code as parts of them, I would have created a
    >> derivative work and would not be allowed to distribute it except if I
    >> was allowed to distribute this malloc replacement according to the
    >> terms of the GPL.

    >
    > Yes, if you did so by a creative process.


    In other words: If I combined [...] to create something which has a
    function of its own. This means that I would have added something
    which depends properties specific to both of the other parts and adds
    something to them which did not exist before I created it. And then, I
    would have made a derivative work of the other two parts. 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.

    >> > And when some third-party links them together, no new work is created.
    >> > This must be so because no creative effort is needed to link them
    >> > together.

    >
    >> A really bad (IMO) German rap band called 'The Fanastic Four' was IIRC
    >> sucessfully sued by J.J. Cale because they incorporated a part of one
    >> of his songs into one of them some time in the first half of the
    >> 1990s. But the act of 'aggregating' two indepedent sounds onto some
    >> medium using a suitable recording device is certainly mechanical and
    >> the recording device cannot create anything on its own. If you were
    >> right, you would have proven that this didn't happen and, by
    >> extension, that HipHop is inherently uncreative in nature.

    >
    > Right, because they did so creatively. They are human beings, they are
    > not automated linkers. The question is whether linking can create a
    > derivative work where one did not exist before.
    >
    > In any event, your example fails for another reason. Suppose I take
    > Sting CDs and add some extra drum hits to them. Of course I can't copy
    > them and sell them.


    This is, of course, true.

  16. Re: module license taints kernel.

    On Mon, 19 Nov 2007 11:15:25 -0800 (PST), David Schwartz wrote:
    > On Nov 16, 3:48 pm, Bob Tennent wrote:
    >
    >> It's not the act of aggregation that's covered or not. It's the act of
    >> *distributing* an aggregate that contains a GPLed work.

    >
    > You can have it either of two ways:
    >
    > 1) It's an aggregate, and the GPL does not require you to distribute
    > the source code of the other works aggregated with the covered work.
    >
    > 2) It's perhaps not an aggregate, and we have to decide if the GPL is
    > in scope or not. Check copyright law, you will find no section that
    > reserves to the copyright holder the right to control the distribution
    > of works that are non-creatively derived from lawful copies.


    So if I take a copyrighted work, apply rot13 to it, the result can be
    freely distributed? I rather doubt it.

    >> The requirements
    >> of the GPL on distributors do *not* apply to the non-GPled components;
    >> that's why the "mere aggregation" clause was suggested by a previous
    >> poster. But a kernel linked with a non-GPLed module is not an aggregate
    >> as defined by the GPL. The GPL doesn't stop you doing it, but it doesn't
    >> allow distribution, which is completely within its scope, or rather the
    >> scope of the copyright owners.

    >
    > You have completely missed my point. If the question is whether the
    > GPL *applies*, how the GPL defines things doesn't matter. The GPL does
    > not get to set its own scope. I am saying the GPL does not *apply* to
    > the work because the work is outside of the GPL's scope as defined by
    > copyright law.


    I've already decided I can't depend on *your* characterization of
    copyright law. I've already stated IANAL; what about you? Frankly, I'll
    trust Eben Moglen, Professor of Law, Columbia Law School, who wouldn't
    have allowed the statements I've quoted if the restrictions weren't
    within the scope of copyright law.

    Bob T.

  17. Re: module license taints kernel.

    On Nov 19, 12:21 pm, Bob Tennent wrote:

    > So if I take a copyrighted work, apply rot13 to it, the result can be
    > freely distributed? I rather doubt it.


    The fact that you applied rot13 to it has no legal consequence
    whatsoever. It's still, for legal purposes, the original work. You can
    do anything with it you could do with the original work.

    > I've already decided I can't depend on *your* characterization of
    > copyright law.


    Then explain where you disagree with it.

    > I've already stated IANAL; what about you? Frankly, I'll
    > trust Eben Moglen, Professor of Law, Columbia Law School, who wouldn't
    > have allowed the statements I've quoted if the restrictions weren't
    > within the scope of copyright law.


    You might as well ask the client's attorney if the client is innocent.

    DS

  18. Re: module license taints kernel.

    On Nov 19, 11:50 am, Rainer Weikusat wrote:

    > > So you rescind your claim that linkers create derivative works?


    > If have never claimed that linkers create derivative works.


    Okay, then maybe I don't know what we're arguing about.

    > > You have a new claim -- that a work fed into a linker might be a
    > > derivative work of some other work. Well, duh, of course it might.


    > No. I still have the original claim, namely, that what is fed into the
    > linker constitutes 'a work'.


    What is fed into the linker is more than one work. You can certainly
    call it a "work" if you like because collections of works are often
    themselves works. What do you think this buys you?

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

    > > Yes, if you did so by a creative process.


    > In other words: If I combined [...] to create something which has a
    > function of its own.


    No. Function is completely irrelevant. Really.

    The question is whether the combination process is creatively
    selective or creatively adds new content. It has nothing to do with
    function, and the rules apply in exactly the same way to non-
    functional works as they do to functional ones.

    > This means that I would have added something
    > which depends properties specific to both of the other parts and adds
    > something to them which did not exist before I created it. And then, I
    > would have made a derivative work of the other two parts.


    Yes, provided this process is creatively selective. The problem is
    that linkers are not creatively selective.

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

    "A 'derivative work' is a work based upon one or more preexisting
    works, such as a translation, musical arrangement, dramatization,
    fictionalization, motion picture version, sound recording, art
    reproduction, abridgment, condensation, or any other form in which a
    work may be recast, transformed, or adapted. A work consisting of
    editorial revisions, annotations, elaborations, or other modifications
    which, as a whole, represent an original work of authorship, is a
    'derivative work'."

    The key is that it, as a whole, represents an original work of
    authorship in which a work is recast, transformed or adapted. Notice
    that it requires things like "revisions", "annotations" and
    "elaborations". These are *creative* extensions of a *creative* work.
    It is *only* creativity that creates an "original work of authorship".

    Copyrights do not vest based on hard work, functionality, or anything
    else *but* creative expression.

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

    If you take two DVDs and combine them in a non-creative way, you still
    just have the two DVDs. If you combine them in a creative way, you
    have a new work. The key is that the creative expression in the
    original works is revised, annotated, or elaborated in by a human
    brain adding expression to those original expressions.

    Note that the fact that you extend the *functionality* of the work
    doesn't matter. Functionality is really and truly irrelevant. In fact,
    functionality counts against copyright. If you take only what you need
    for functional purposes, copyright does *NOT* apply.

    DS

  19. Re: module license taints kernel.

    On Tue, 20 Nov 2007 08:49:27 -0800 (PST), David Schwartz wrote:
    > On Nov 19, 12:21 pm, Bob Tennent wrote:
    >
    >> So if I take a copyrighted work, apply rot13 to it, the result can be
    >> freely distributed? I rather doubt it.

    >
    > The fact that you applied rot13 to it has no legal consequence
    > whatsoever. It's still, for legal purposes, the original work. You can
    > do anything with it you could do with the original work.


    But one cannot distribute or modify a copyrighted work except as
    licensed by the copyright holder; so that would apply to a non-creative
    modification as well.

    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.

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

    Bob T.

  20. Re: module license taints kernel.

    David Schwartz writes:
    > On Nov 19, 11:50 am, Rainer Weikusat wrote:
    >> > So you rescind your claim that linkers create derivative works?

    >
    >> If have never claimed that linkers create derivative works.

    >
    > Okay, then maybe I don't know what we're arguing about.


    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.

    >> > You have a new claim -- that a work fed into a linker might be a
    >> > derivative work of some other work. Well, duh, of course it might.

    >
    >> No. I still have the original claim, namely, that what is fed into the
    >> linker constitutes 'a work'.

    >
    > What is fed into the linker is more than one work.


    This depends on what is fed into the linker.

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

    >> > Yes, if you did so by a creative process.

    >
    >> In other words: If I combined [...] to create something which has a
    >> function of its own.

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

    [...]

    >> This means that I would have added something which depends
    >> properties specific to both of the other parts and adds
    >> something to them which did not exist before I created it. And
    >> then, I would have made a derivative work of the other two parts.

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

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

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

    [...]

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

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