Mailing List Archive: Linux: Kernel

GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

1 2 3 4 5 6 7 8 9

View All

Index | Next | Previous | View Threaded

karderio at gmail

Dec 18, 2006, 1:04 PM

Post #151 of 214 (3130 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Hi :o)

On Fri, 2006-12-15 at 18:55 -0800, Linus Torvalds wrote:
> But the point is, "derived work" is not what _you_ or _I_ define. It's
> what copyright law defines.

Of course not. I never suggested trying to define a derived work.

> And trying to push that definition too far is a total disaster. If you
> push the definition of derived work to "anything that touches our work",
> you're going to end up in a very dark and unhappy place. One where the
> RIAA is your best buddy.

I don't see how what is proposed for blocking non GPL modules at all
touches the definition of derived work. Even if according to law and the
GPL, binary modules are legal, the proposed changes could still be
made.

I have realised that the proposed changes do not *impose* any more
restriction on the use of the kernel than currently exists. Currently
the Kernel is licenced to impose the same licence on derived works,
enforce distribution of source code etc. and this by law. The proposed
changes do not impose anything, they just make things technically a
little more complicated for some, and they can be trivially circumvented
if one desires. Maybe not a good idea, but still no excuse for the sort
of atrocious bigotry some people are exhibiting here.

I do not mean to say this is a good thing, some of the arguments
advanced here make me much less enthusiastic as at the beginning. As I
said in my first post, and seemed to be promptly ignored, this can only
by any use at all if it persuades vendors to provide the essential
information about their products without hurting users too much, or
further alienating vendors. All this is of course highly debatable, and
needs discussing properly, if people are able to communicate in a civil
manner that is.

Before any fanatic ranting saying that people inducing slight
complications are freedom hating Nazis who should be burned at the
stake, please contrast this trivial complication with the extremely
difficult work that must be done by someone wanting to write a driver
when a vendor doesn't provide adequate documentation.

It might be noted that in some countries it is quite illegal not to
provide documentation for a product, just as it is illegal to limit a
product to only work with a specific vendors merchandise when said
product is in essence generic. This is the case in France, where these
laws are simply ignored by corporations. A large French NFP sued HP last
week about them not allowing their PCs to be sold without Windows, so we
may finally start to get these laws applied. I have written the NFP to
suggest that if the case does not extend to missing hardware
documentation, maybe another case would be in order. In the past the
people at this NFP have been very civil and cooperative with me.

> And that is why it would be WRONG to think that we have the absolute right
> to say "that is illegal". It's simply not our place to make that
> judgement. When you start thinking that you have absolute control over the
> content or programs you produce, and that the rest of the worlds opinions
> doesn't matter, you're just _wrong_.

I have seen nobody with the ponce to judge people or try to have control
over them when arguing for these mods. I think all that has been said
has been people trying to interpret the law, it's quite possible they
got it wrong. Not that I can blame them, law is a not simple, and I can
see people on both "sides" of the argument not getting things quite
right here.

I would note however that I personally find it distasteful to call
people "wrong" rather than respectfully disagreeing with them.

> So don't go talking about how we should twist peoples arms and force them
> to be open source of free software. Instead, BE HAPPY that people can take
> advantage of "loopholes" in copyright protections and can legally do
> things that you as the copyright owner might not like. Because those
> "loopholes" are in the end what protects YOU.

I admit I should not have used the phrase "twist arm", I meant it in an
entirely jocular sense, it is a phrase I never employ usually. Of course
it is a mistake I regret. The word "persuade" would have been a much
better choice.

As I hope I clearly explained above, it wasn't suggested to "force"
anybody to do anything.

Although I don't appreciate insult or aggressively, I choose to ignore
it in order to try and advance a reasonable discussion. I will not stand
here and let you tell me what to and not to do however. It also makes
you seem a bit hypocritical in a discussion where you are claiming to be
arguing for "freedom".

Love, Karderio.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

davids at webmaster

Dec 18, 2006, 1:23 PM

Post #152 of 214 (3141 views)
Permalink

RE: GPL only modules [In reply to]

> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> static linking aggregates the library with the other program in the same
> binary. There's no question about that. And that _does_ have meaning from
> a copyright law angle, since if you don't have permission to ship
> aggregate works under the license, then you can't ship said binary. It's
> just a non-issue in the specific case of the GPLv2.

The right to ship aggregate works is not one specifically reserved by law to
the copyright holder. It's also not clear that an aggregate work is in fact
a single work for any legal purpose other than the aggregator's claim to
copyright. All you need to ship an aggregated work is the right to ship each
of the individual works aggregated in it. For GPL'd works, you get that
right from first sale, assuming you lawfully acquired the GPL'd work in the
first place.

If the aggregation is performed in an automated and mechanized way, the
aggregate is not a single work. It's still multiple works aggregated
together. For copyright law purposes, it is not a work because no creative
input was needed to produce it beyond what was used to create the works from
which it was formed.

I recently bought two DVDs as a present for a friend of mine. I put the two
DVDs in one box and shipped them to him. Just because the two DVDs are in
one box does not make them a derivative work for copyright purposes because
no creative input went in to them. I can even staple the two DVDs together
if I want. I also don't need any special permission to ship the two of them
together to my friend, first sale covers that. The right to ship each
individual work is all that's needed to ship the aggregate.

Now, if I wanted to write my own story with elements from the content of
both DVDs, that would be a derivative work because the combination itself is
done in a creative way.

No automated, mechanical process can create a derivative work of software.
(With a few exceptions not relevant here.)

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

tytso at mit

Dec 18, 2006, 2:05 PM

Post #153 of 214 (3135 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Mon, Dec 18, 2006 at 10:04:07PM +0100, karderio wrote:
> I have realised that the proposed changes do not *impose* any more
> restriction on the use of the kernel than currently exists. Currently
> the Kernel is licenced to impose the same licence on derived works,
> enforce distribution of source code etc. and this by law. The proposed
> changes do not impose anything, they just make things technically a
> little more complicated for some, and they can be trivially circumvented
> if one desires.

.... except that the people who proposed these changes have already
suggested that these circumventions would be violations of the United
States' Digital Milllenium Copyright Act, which has rather draconoian
penalties for these "trivial circumventions". Which is precisely why
Linus has said that if we go down this path, we are basically using
the same tactics as the RIAA and MPAA. And why this kind of arm
twisting as "pursuasion" would be a very, VERY bad idea.

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jmerkey at wolfmountaingroup

Dec 18, 2006, 2:06 PM

Post #154 of 214 (3144 views)
Permalink

Re: GPL only modules [In reply to]

Linus Torvalds wrote:

>On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>
>
>>>In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>>>
>>>
>>Agreed. So what? How does this relate with the point above?
>>
>>The binary is a Program, as much as the sources are a Program. Both
>>forms are subject to copyright law and to the license, in spite of
>>http://www.fsfla.org/?q=en/node/128#1
>>
>>
>
>Here's how it relates:
> - if a program is not a "derived work" of the C library, then it's not
> "the program" as defined by the GPLv2 AT ALL.
>
>In other words, it doesn't matter ONE WHIT whether you use "ld --static"
>or "ld" or "mkisofs" - if the program isn't (by copyright law) derived
>from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY
>AFFECT THE RESULTING BINARY.
>
>And I'm simply claiming that a binary doesn't become "derived from" by any
>action of linking.
>
>Even if you link using "ld", even if it's static, the binary is not
>"derived from". It's an aggregate.
>
>"Derivation" has nothing to do with "linking". Either it's derived or it
>is not, and "linking" simply doesn't matter. It doesn't matter whether
>it's static or dynamic. That's a detail that simply doesn't have anythign
>at all to do with "derivative work".
>
>THAT is my point.
>
>Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
>static linking aggregates the library with the other program in the same
>binary. There's no question about that. And that _does_ have meaning from
>a copyright law angle, since if you don't have permission to ship
>aggregate works under the license, then you can't ship said binary. It's
>just a non-issue in the specific case of the GPLv2.
>
>In the presense of dynamic linking the binary isn't even an aggregate
>work.
>
>THAT is the difference between static and dynamic. A simple command line
>flag to the linker shouldn't really reasonably be considered to change
>"derivation" status.
>
>Either something is derived, or it's not. If it's derived, "ld",
>"mkisofs", "putting them close together" or "shipping them on totally
>separate CD's" doesn't matter. It's still derived.
>
> Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo[at]vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Yep. We love you linus, keep going.

Also, we are taking over SCO's office space after the first of the year,
since they have no one left. We will try to get that annoying eyesore of
a sign taken off the building as soon as possible. They moved to
Holliday, UT (or are moving there at present).

:-)

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at osdl

Dec 18, 2006, 2:11 PM

Post #155 of 214 (3126 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Mon, 18 Dec 2006, karderio wrote:
>
> I don't see how what is proposed for blocking non GPL modules at all
> touches the definition of derived work. Even if according to law and the
> GPL, binary modules are legal, the proposed changes could still be
> made.

.. and then what does that mean? It means that we try to say that people
cannot do what they LEGALLY can do?

In other words, it means that we are pushing a agenda that is no longer
neither a technical issue (it's clearly technically _worse_ to not be able
to do something) _nor_ a legal issue.

So tell me, what does the proposed blocking actually do?

It's "big prother, FSF style". And I say NO THANK YOU.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hch at infradead

Dec 18, 2006, 2:14 PM

Post #156 of 214 (3131 views)
Permalink

Re: GPL only modules [In reply to]

On Mon, Dec 18, 2006 at 05:41:17PM -0200, Alexandre Oliva wrote:
> On Dec 17, 2006, Kyle Moffett <mrmacman_g4[at]mac.com> wrote:
>
> > On the other hand, certain projects like OpenAFS, while not license-
> > compatible, are certainly not derivative works.
>
> Certainly a big chunk of OpenAFS might not be, just like a big chunk
> of other non-GPL drivers for Linux.
>
> But what about the glue code? Can that be defended as not a derived
> work, such that it doesn't have to be GPL?

Actually the OpenAFS kernel code almost 100% is a derived work of both
the original AFS codebase and Linux. Just go and take a look at it,
there's shitloads of copy & paste and very deep poking into kernel internals.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

sepreece at gmail

Dec 18, 2006, 2:35 PM

Post #157 of 214 (3138 views)
Permalink

Re: GPL only modules [In reply to]

On 12/18/06, David Schwartz <davids[at]webmaster.com> wrote:
>
> > Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> > static linking aggregates the library with the other program in the same
> > binary. There's no question about that. And that _does_ have meaning from
> > a copyright law angle, since if you don't have permission to ship
> > aggregate works under the license, then you can't ship said binary. It's
> > just a non-issue in the specific case of the GPLv2.
>
> The right to ship aggregate works is not one specifically reserved by law to
> the copyright holder.
---
Well, it's reserved to the authors of all the works in the aggregate,
possibly including the person doing the aggregation. And the author of
each of those works does have the right to limit your permission to
distribute in ways that might bar use in aggregations.
---
> It's also not clear that an aggregate work is in fact
> a single work for any legal purpose other than the aggregator's claim to
> copyright.
---

Not sure what you're trying to say there - what are we talking about
here other than the copyright?

---
> All you need to ship an aggregated work is the right to ship each
> of the individual works aggregated in it. For GPL'd works, you get that
> right from first sale, assuming you lawfully acquired the GPL'd work in the
> first place.
---

An aggregate work (the word used in the Copyright Act is either
"Compilation" or "Collective work", depending on the level of
creativity involved in forming it). In either case it is an
independent work. The person creating a Compilation has, at the least,
copyright in the organization of the material, plus copyright in any
original material she contributes. I agree, however, that all you need
to distribute tthe compilation is permission to distribute each of the
pieces in the given form (the author could have given you the right to
distribute only in conjunction with other specified works, for
instance) or placed other restrictions on the license.

First sale has nothing to do with this. First sale applies to the
redistribution or resale of copies you have purchased, not with the
right to make additional copies.

---
> ... For copyright law purposes, it is not a work because no creative
> input was needed to produce it beyond what was used to create the works from
> which it was formed.
---

Selection and organization are potentially creative. The Act
distinguishes between derivative works, compilations, and collective
works. A derivative work is a work "based on" the original work; a
compilation is a work formed by "collecting and assembling"
preexisting works "in such a way that the resulting work as a whole
constitutes an original work of authorship. A "collective work" is any
work formed by assembling independent works into a whole. All
compilations are collective works, but not all collective works are
compilations. Derivative works have nothing to do with aggregation.

---
> I recently bought two DVDs as a present for a friend of mine. I put the two
> DVDs in one box and shipped them to him. Just because the two DVDs are in
> one box does not make them a derivative work for copyright purposes because
> no creative input went in to them. I can even staple the two DVDs together
> if I want. I also don't need any special permission to ship the two of them
> together to my friend, first sale covers that. The right to ship each
> individual work is all that's needed to ship the aggregate.
---

First sale is separate from Copyright. You have the right to ship
them, but not to make copies of them. You can't for instance, ship
your friend a single DVD that combines the contents of the two you
bought. That's not unlike the distinction GPLv3 makes between
"propagating" and "conveying".

---
>
> Now, if I wanted to write my own story with elements from the content of
> both DVDs, that would be a derivative work because the combination itself is
> done in a creative way.
---

If it just rearranged the pieces, it would not be a derivative work,
it would be a compilation. If you transformed the pieces, it might be
a derivative work (depending on the nature of the transformation).

---
>
> No automated, mechanical process can create a derivative work of software.
> (With a few exceptions not relevant here.)
---

The truth of that statement depends on exactly what you mean by "an
automated, mechanical process". There are mechanical processs that
would simply produce the original work itself, not a derivative (e.g.,
changing the type from Courier to Times). There are other mechanical
proceses that would produce a collective work (e.g., inserting after
each line of the program a statement indicating whether or not it was
valid C). There are other mechanical processes that would create a
derivative work (e.g., a paraphrasing tool). It depends on the nature
of the mechanical process; that is, the decision, by you, to apply a
particular mechanical process is itself creative. But, perhaps that's
what you meant by your "few exceptions".

As always, IANAL,
scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

sepreece at gmail

Dec 18, 2006, 2:42 PM

Post #158 of 214 (3126 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On 12/18/06, Linus Torvalds <torvalds[at]osdl.org> wrote:
>
> In other words, it means that we are pushing a agenda that is no longer
> neither a technical issue (it's clearly technically _worse_ to not be able
> to do something) _nor_ a legal issue.
>
> So tell me, what does the proposed blocking actually do?
>
> It's "big prother, FSF style". And I say NO THANK YOU.
>
> Linus
---

Well, you can't really say it's "FSF-style", since the GPLv3 language
explicitly gives permission to circumvent any protection measures
implemented by a GPLv3 program. Even the FSF doesn't support using
the DMCA to support GPL restrictions.

scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

paulus at samba

Dec 18, 2006, 3:16 PM

Post #159 of 214 (3129 views)
Permalink

Re: GPL only modules [In reply to]

Junio C Hamano writes:

> Excuse me, but are you two discussing "ld"? ;-)

Oops. Yes. :)

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

aoliva at redhat

Dec 18, 2006, 3:28 PM

Post #160 of 214 (3125 views)
Permalink

Re: GPL only modules [In reply to]

On Dec 18, 2006, Linus Torvalds <torvalds[at]osdl.org> wrote:

> On Mon, 18 Dec 2006, Alexandre Oliva wrote:

>> > In other words, in the GPL, "Program" does NOT mean "binary". Never has.

>> Agreed. So what? How does this relate with the point above?

> Here's how it relates:
> - if a program is not a "derived work" of the C library, then it's not
> "the program" as defined by the GPLv2 AT ALL.

In the case I'm talking about, libgpl (make it a GPLed libc) is the
program, and a binary produced by linking anything else with the
program (libgpl) is what you claim to be an aggregate (a term not
defined in the GPL; is it defined in US law?).

For both static and dynamic linking, you might claim the output is an
aggregate, but that doesn't matter. What matters is whether or not
the output is a work based on the program, and whether the "mere
aggregation" paragraph kicks in.

If the output is not an aggregate, which is quite likely to be
the case for dynamic linking, and quite possibly also for many static
linking cases, then the "mere aggregation" paragraph of clause 2 does
not kick in.

If the output is indeed an aggregate, as it may quite likely be in the
case of static linking, then the "mere aggregation" considerations of
clause 2 may kick in and enable the 'anything else' to not be brought
under the scope of the license. You still need permission to
distribute the whole. The GPL asserts its non-interference with your
ability to distribute the separate portion separately, under whatever
license you can, as long as it's not a derived work from the GPL
portion.

But what about the whole? If you can't separate the whole into, well,
the separate components, is it still a mere aggregate? mkisofs will
create an image in which the components are all there, easily
extractable individually in their original form. This is *clearly*
mere aggregation, even if some components turn out to be works based
on other GPL programs.

But even in the case of static linking, this is not how it works.
Say, if the portions of the static libgpl to be copied to the output
are selected based on the contents of the 'anything else', could you
legitimately claim that the output is not a derived work of both
libgpl and this 'anything else', but rather a mere aggregation of
unrelated works?

In either case, if you distribute the linker output, and it happens to
be found to be a derived work of the program (libgpl), aggregate or
not, then you must license the whole of the linker output under the
GPL, and this means to me that you have to be able to provide the
source code of every portion thereof under the GPL, except for
portions explicitly excluded by the GPL itself.

So whether it's an aggregate or not is completely irrelevant. What
matters is whether it's a derived work of a GPLed program (and if
there is copying, it probably is) and whether the mere aggregation
clause kicks in to grant an exception.

> THAT is the difference between static and dynamic. A simple command line
> flag to the linker shouldn't really reasonably be considered to change
> "derivation" status.

If in one case there is extraction, copying and transformation of the
GPLed intput, and in the other there is something much simpler (does
it still qualify as extraction, copying and transformation?), then
derivation becomes more or less obvious to prove, but you're right in
that the status of the output probably won't change. The status of
the inputs certainly doesn't.

> Either something is derived, or it's not. If it's derived, "ld",
> "mkisofs", "putting them close together" or "shipping them on totally
> separate CD's" doesn't matter. It's still derived.

But the important questions at hand, I think, are what makes it
derived, and whether it qualifies for any of the exceptions in the
GPL.

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

paulus at samba

Dec 18, 2006, 3:52 PM

Post #161 of 214 (3141 views)
Permalink

Re: GPL only modules [In reply to]

Linus Torvalds writes:

> "Derivation" has nothing to do with "linking". Either it's derived or it
> is not, and "linking" simply doesn't matter. It doesn't matter whether
> it's static or dynamic. That's a detail that simply doesn't have anythign
> at all to do with "derivative work".

There is in fact a pretty substantial non-technical difference between
static and dynamic linking. If I create a binary by static linking
and I include some library, and I distribute that binary to someone
else, the recipient doesn't need to have a separate copy of the
library, because they get one in the binary.

If on the other hand the binary is dynamically linked, then the
recipient needs to get hold of a copy of the library from somewhere,
implying that they need to have satisfied whatever license conditions
the copyright owner of the library places on it, in order to have
obtained their copy of the library legally.

In other words, static linking gives the recipient a "free" copy of
the library, but dynamic linking doesn't. That is why some companies'
legal guidelines have quite different rules about the distribution of
binaries, depending on whether they are statically or dynamically
linked.

If the library was a proprietary library, for which the copyright
owner wanted to charge a per-copy fee, the owner would no doubt object
to me distributing statically-linked binaries containing his library,
but could conceivably be perfectly happy with me distributing binaries
that have been dynamically linked against his library, since then
anyone who wants to use my binary has to purchase a copy of his
library from him.

So therefore I don't think you can reasonably claim that static
vs. dynamic linking is only a technical difference. There are clearly
other differences when it comes to distribution of the resulting
binaries.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at osdl

Dec 18, 2006, 3:59 PM

Post #162 of 214 (3132 views)
Permalink

Re: GPL only modules [In reply to]

On Tue, 19 Dec 2006, Paul Mackerras wrote:
>
> There is in fact a pretty substantial non-technical difference between
> static and dynamic linking. If I create a binary by static linking
> and I include some library, and I distribute that binary to someone
> else, the recipient doesn't need to have a separate copy of the
> library, because they get one in the binary.

I agree, and I do agree that it's a real difference.

I personally think that it's the "aggregation" issue, not a "derivation"
issue, but I'll freely admit that it's just my personal view of the
situation.

> In other words, static linking gives the recipient a "free" copy of
> the library, but dynamic linking doesn't. That is why some companies'
> legal guidelines have quite different rules about the distribution of
> binaries, depending on whether they are statically or dynamically
> linked.

Yes. There is not doubt at all that regardless of anything else, if you
link statically, you at the VERY LEAST need to have the right to
distribute the library as part of an "aggregate work".

> So therefore I don't think you can reasonably claim that static
> vs. dynamic linking is only a technical difference. There are clearly
> other differences when it comes to distribution of the resulting
> binaries.

Yes. And I have actually talked about this exact issue - even in the
absense of any "derivation" from the library, the fact that static linking
includes a _copy_ of the library does mean that you have to have the right
to distribute that particular copy.

Now, under the GPL, aggregate distribution is allowed, but you still do
need to follow the other GPL rules (ie you would need to distributed
sources for the library - even if you don't necessarily distribute sources
to the binary you linked _with_).

So there's no question that "dynamic linking" simplifies issues, by virtue
of not even distributing any library code at all. I absolutely agree about
that part.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

paulus at samba

Dec 18, 2006, 4:43 PM

Post #163 of 214 (3117 views)
Permalink

Re: GPL only modules [In reply to]

Linus Torvalds writes:
>
>
> On Tue, 19 Dec 2006, Paul Mackerras wrote:
> >
> > There is in fact a pretty substantial non-technical difference between
> > static and dynamic linking. If I create a binary by static linking
> > and I include some library, and I distribute that binary to someone
> > else, the recipient doesn't need to have a separate copy of the
> > library, because they get one in the binary.
>
> I agree, and I do agree that it's a real difference.
>
> I personally think that it's the "aggregation" issue, not a "derivation"
> issue, but I'll freely admit that it's just my personal view of the
> situation.

I think the critical issue is whether any human creativity is required
to establish derivation.

Clearly there is some modification and adaptation that ld does to a
library in the process of linking it into a binary, and ld is unlike
mkisofs or gzip in that you can't extract the library in its original
form (or any form suitable for linking with another program) from the
output of ld --static.

The question is whether it matters that the process that ld does is
mechanical in nature. This is possibly an area where you'll get a
different answer in different jurisdictions. I believe that in the
US, some creative input is required to establish copyright, whereas in
Australia, only "effort" is needed. I don't know whether that affects
the definition of "derived work".

I personally would think that a mechanical process of modification
*does* create a derived work, but it would take a court of law or a
legislature to make an authoritative decision, I guess.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

davids at webmaster

Dec 18, 2006, 5:29 PM

Post #164 of 214 (3131 views)
Permalink

RE: GPL only modules [In reply to]

> > It's also not clear that an aggregate work is in fact
> > a single work for any legal purpose other than the aggregator's claim to
> > copyright.

> Not sure what you're trying to say there - what are we talking about
> here other than the copyright?

We are talking about two different possible copyright claims. One is the
person who aggregates the works who may try to claim a "compilation
copyright" in the aggregate. The other is the authors of the original works
who may try to claim that the aggregate is a derivative work.

> First sale has nothing to do with this. First sale applies to the
> redistribution or resale of copies you have purchased, not with the
> right to make additional copies.

First sale is exactly what this is about. Nobody needs to make "additional
copies" of the Linux kernel because I can download a thousand of them from a
computer operated by the guy in the office down the hall from me.

> > ... For copyright law purposes, it is not a work because no creative
> > input was needed to produce it beyond what was used to create
> > the works from
> > which it was formed.

> Selection and organization are potentially creative. The Act
> distinguishes between derivative works, compilations, and collective
> works. A derivative work is a work "based on" the original work; a
> compilation is a work formed by "collecting and assembling"
> preexisting works "in such a way that the resulting work as a whole
> constitutes an original work of authorship. A "collective work" is any
> work formed by assembling independent works into a whole. All
> compilations are collective works, but not all collective works are
> compilations. Derivative works have nothing to do with aggregation.

Good, so we agree that aggregate is not a derivative work. That means it
doesn't have to be GPL'd even if some of its component works are GPL'd.

> > I recently bought two DVDs as a present for a friend of mine. I
> > put the two
> > DVDs in one box and shipped them to him. Just because the two
> > DVDs are in
> > one box does not make them a derivative work for copyright
> > purposes because
> > no creative input went in to them. I can even staple the two
> > DVDs together
> > if I want. I also don't need any special permission to ship the
> > two of them
> > together to my friend, first sale covers that. The right to ship each
> > individual work is all that's needed to ship the aggregate.

> First sale is separate from Copyright. You have the right to ship
> them, but not to make copies of them. You can't for instance, ship
> your friend a single DVD that combines the contents of the two you
> bought. That's not unlike the distinction GPLv3 makes between
> "propagating" and "conveying".

I don't see why you can't distribute a single DVD that combines the contents
of the two you bought, so long as you destroy the originals. There is no
issue about the number of copies with the GPL because you can download any
number of copies of a GPL'd work from someone else who provides you with
source.

> > Now, if I wanted to write my own story with elements from the content of
> > both DVDs, that would be a derivative work because the
> > combination itself is
> > done in a creative way.

> If it just rearranged the pieces, it would not be a derivative work,
> it would be a compilation. If you transformed the pieces, it might be
> a derivative work (depending on the nature of the transformation).

I think it depends upon how small the pieces are. If you rearranged them
creatively, and the result was in effect a single work, I think it would be
a derivative work.

> > No automated, mechanical process can create a derivative work
> > of software.
> > (With a few exceptions not relevant here.)

> The truth of that statement depends on exactly what you mean by "an
> automated, mechanical process". There are mechanical processs that
> would simply produce the original work itself, not a derivative (e.g.,
> changing the type from Courier to Times). There are other mechanical
> proceses that would produce a collective work (e.g., inserting after
> each line of the program a statement indicating whether or not it was
> valid C). There are other mechanical processes that would create a
> derivative work (e.g., a paraphrasing tool). It depends on the nature
> of the mechanical process; that is, the decision, by you, to apply a
> particular mechanical process is itself creative. But, perhaps that's
> what you meant by your "few exceptions".

I mean that you can't link together a bunch of works that would otherwise be
independent and get a derivative work as a result. Linking combines
mechanistically, not creatively, so it aggregates.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

davids at webmaster

Dec 18, 2006, 5:35 PM

Post #165 of 214 (3141 views)
Permalink

RE: GPL only modules [In reply to]

> For both static and dynamic linking, you might claim the output is an
> aggregate, but that doesn't matter. What matters is whether or not
> the output is a work based on the program, and whether the "mere
> aggregation" paragraph kicks in.
>
> If the output is not an aggregate, which is quite likely to be
> the case for dynamic linking, and quite possibly also for many static
> linking cases, then the "mere aggregation" paragraph of clause 2 does
> not kick in.
>
> If the output is indeed an aggregate, as it may quite likely be in the
> case of static linking, then the "mere aggregation" considerations of
> clause 2 may kick in and enable the 'anything else' to not be brought
> under the scope of the license. You still need permission to
> distribute the whole. The GPL asserts its non-interference with your
> ability to distribute the separate portion separately, under whatever
> license you can, as long as it's not a derived work from the GPL
> portion.

No!

It makes no difference whether the "mere aggregation" paragraph kicks in
because the "mere aggregation" paragraph is *explaining* the *law*. What
matters is what the law actually *says*.

We are talking about what works are within the GPL's scope. The text of the
GPL does not matter because the GPL does not set its own scope, copyright
law does.

The GPL could say that if you ever see the source code to a GPL'd work,
every work you ever write must be placed under the GPL. But that wouldn't
make it true, because that would be a requirement outside the GPL's scope.

We are talking about works are inside the GPL's legal scope, and in that
case, nothing the GPL says can enlarge the scope.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

davids at webmaster

Dec 18, 2006, 5:39 PM

Post #166 of 214 (3135 views)
Permalink

RE: GPL only modules [In reply to]

Combined responses:

> So therefore I don't think you can reasonably claim that static
> vs. dynamic linking is only a technical difference. There are clearly
> other differences when it comes to distribution of the resulting
> binaries.

We're only talking about the special case of GPL'd works. You can download a
million copies of a GPL'd work from a server run by a family member across
the room. You can then delete one copy for each copy you distribute in the
form of a statically linked work.

Issues of copying don't apply to GPL'd works unless you have no access to
the source code. Otherwise, someone else can copy you as many works as you
want with the source code, and you can use first sale to transfer every one
of them.

> I personally would think that a mechanical process of modification
> *does* create a derived work, but it would take a court of law or a
> legislature to make an authoritative decision, I guess.

Under at least United States law, copyright protected creative expression
and only creative expression. In other jurisdictions, there are other types
of rights similar to copyright that one can obtain by means of hard work,
for example database compilation rights. They are usually legally distinct
from copyright and grant different rights with different rules.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dhazelton at enter

Dec 18, 2006, 6:38 PM

Post #167 of 214 (3133 views)
Permalink

Re: GPL only modules [In reply to]

On Monday 18 December 2006 20:35, David Schwartz wrote:
> > For both static and dynamic linking, you might claim the output is an
> > aggregate, but that doesn't matter. What matters is whether or not
> > the output is a work based on the program, and whether the "mere
> > aggregation" paragraph kicks in.
> >
> > If the output is not an aggregate, which is quite likely to be
> > the case for dynamic linking, and quite possibly also for many static
> > linking cases, then the "mere aggregation" paragraph of clause 2 does
> > not kick in.
> >
> > If the output is indeed an aggregate, as it may quite likely be in the
> > case of static linking, then the "mere aggregation" considerations of
> > clause 2 may kick in and enable the 'anything else' to not be brought
> > under the scope of the license. You still need permission to
> > distribute the whole. The GPL asserts its non-interference with your
> > ability to distribute the separate portion separately, under whatever
> > license you can, as long as it's not a derived work from the GPL
> > portion.
>
> No!
>
> It makes no difference whether the "mere aggregation" paragraph kicks in
> because the "mere aggregation" paragraph is *explaining* the *law*. What
> matters is what the law actually *says*.
>
> We are talking about what works are within the GPL's scope. The text of the
> GPL does not matter because the GPL does not set its own scope, copyright
> law does.
>
> The GPL could say that if you ever see the source code to a GPL'd work,
> every work you ever write must be placed under the GPL. But that wouldn't
> make it true, because that would be a requirement outside the GPL's scope.
>
> We are talking about works are inside the GPL's legal scope, and in that
> case, nothing the GPL says can enlarge the scope.
>
> DS

Actually, after rereading the GPLv2 because of this discussion I came to a
most surprising conclusion. While there are *IMPLICIT* and *EXPLICIT*
copyrights on the code, they have no bearing on the text of the GPL.

The GPL is a License that covers how the code may be used, modified and
distributed. This is the reason that the FSF people had to make the big
exception for Bison, because the parser skeleton is such an integral part of
Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the
program) that truthfully, any parser built using Bison is a derivative work
of code released under the GPL.

That said, since there is a distribution, use and modification license on the
Linux Kernel - the GPLv2 - there are those extra restrictions on the code
*OUTSIDE* the copyright rules.

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dhazelton at enter

Dec 18, 2006, 7:42 PM

Post #168 of 214 (3134 views)
Permalink

Re: GPL only modules [In reply to]

On Monday 18 December 2006 14:41, Alexandre Oliva wrote:
> On Dec 17, 2006, Kyle Moffett <mrmacman_g4[at]mac.com> wrote:
> > On the other hand, certain projects like OpenAFS, while not license-
> > compatible, are certainly not derivative works.
>
> Certainly a big chunk of OpenAFS might not be, just like a big chunk
> of other non-GPL drivers for Linux.
>
> But what about the glue code? Can that be defended as not a derived
> work, such that it doesn't have to be GPL?

That has never been an issue, really. Its what 99% of the binary drivers
believe - hence the reason that there is the user-compiled component to all
of them.

> If not, can the whole containing both the non-derivative work and the
> source code providing the glue without which the whole wouldn't
> fulfill its intended purpose be regarded as a mere aggregate, and thus
> not be subject to the requirement that the whole be released under the
> GPL?

The view that binary vendors take is "Linking does not create a derived
work" - regardless of the fact that you cannot have a complete compiled
program or module *WITHOUT* that linking. However I have a feeling that the
lawyers in the employ of the companies that ship BLOB drivers say that all
they need to do to comply with the GPL is to ship the glue-code in source
form.

And I have to admit that this does seem to comply with the GPL - to the
letter, if not the spirit.

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

barkalow at iabervon

Dec 18, 2006, 8:20 PM

Post #169 of 214 (3141 views)
Permalink

Re: GPL only modules [In reply to]

On Mon, 18 Dec 2006, Linus Torvalds wrote:

> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> static linking aggregates the library with the other program in the same
> binary. There's no question about that. And that _does_ have meaning from
> a copyright law angle, since if you don't have permission to ship
> aggregate works under the license, then you can't ship said binary. It's
> just a non-issue in the specific case of the GPLv2.

Under US law, the distinction is between works that are copyrightable
themselves as "derivative works" and works that are derived from others,
but aren't copyrightable. Provided you're allowed to ship aggregate works,
the question is whether the output of "ld" is a copyrightable work
distinct from the inputs.

I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I
think that "objcopy" does create a derived work, and "ld" does too, by
virtue of modifying the objects it takes to resolve symbols. Now, you
could distribute to somebody an ar archive of your program, and the
recipient (given fair use rights to the copy of the program they received)
could do "gcc program.a -o program" to link it. But I don't think you
automatically get the right (under the "mere aggregation" permission) to
distribute the result of relocating the symbols of gnutls around those of
your program and vice versa, along with modifying the references to
external symbols from each of these to point to specific locations.

-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dhazelton at enter

Dec 18, 2006, 10:35 PM

Post #170 of 214 (3132 views)
Permalink

Re: GPL only modules [In reply to]

On Monday 18 December 2006 12:16, David Schwartz wrote:
> Combined responses to save bandwidth and reduce the number of times people
> have to press "d".
>
> > Agreed. You missed the point.
>
> I don't understand how you could lead with "agreed" and then proceed to
> completely ignore the entire point I just made.

I *initially* thought you had missed the point. After your later post
clarifying things I saw that my statement had been in error and that I did
agree with you completely.

> > Since the Linux Kernel header files
> > contain a
> > chunk of the source code for the kernel in the form of the macros
> > for locking
> > et. al. then using the headers - including that code in your
> > module - makes
> > it a derivative work.
>
> No, it does not. The header files are purely function and not expressive in
> this case. Copyright only protects one choice among many equally-practical
> choices for expressing the same idea or performing the same function.

In this case, well. We aren't talking Copyright, but the license under which
the software is distributed. According to the USPTO placing a statement such
as (c) 2006 Pornrat Watanabe on a work you have created automatially places
it under a copyright. The kernel source code, copyrighted as it is, is then
distributed under the terms of the GNU GPL.

Using the code from the header files may not make the module a derivative, but
it is including parts of a copyrighted work. By *NOT* complying with the
license under which said copyrighted work is distributed, you are giving up
your rights under the license.

This doesn't negate any problems with people making Blob drivers, because, as
you pointed out, under the same laws they aren't a derivative work, which
means that that clause of the license doesn't apply. Now if the GPL contained
a clause specifically defining what it considered a derivative work things
would be different.

> > Actually, thinking about it, the way a Linux driver module works actually
> > seems to make *ANY* driver a derivative work, because they are
> > loaded into
> > the kernels memory space and cannot function without having that done.
>
> If every practical way of expressing an idea contains something, then that
> something is *not* protectable when used to express an idea of that kind.

Not what I was saying. There are any number of ways to make a driver
function - the FUSE system has shown that clearly. But by making that driver
one that is loaded directly into the kernels memory space...

It's that act that *I* *FEEL* makes it a derivative work.

> > *IF* the "Usermode Driver" interface that is being worked on ever proves
> > useful then, and only then, could you consider it *NOT* a
> > derivative work.
> > Because then the only thing it is using *IS* an interface, not complete
> > chunks of the source as generated when the pre-processor finishes running
> > through the file.
>
> No, you have it completely backwards.

No, you missed my point. I was saying that the Usermode Driver interface would
make the current style of kernel modules fully derivative works. This being
because they are using an open system interface and *NOT* including code
distributed with the kernel.

> If a usermode driver interface was equally practical to develop a
> particular type of driver, then using the kernel headers would make the
> driver a derivative work. Because, in that case, the choice to use the
> kernel headers would be a creative choice -- one chosen method among many
> equally practical one.

And this is what I was saying. Perhaps I didn't state it in clear and concise
english.

> Copyright only protects creative choices, not purely functional ones.
>
> "A Linux 2.6 driver for the ATI X800 graphics chipset" is an idea. If the
> only reasonably practical way to express that idea is with the Linux kernel
> header files, then using the Linux kernel header files is scenes a fair,
> not protected content.

Okay. I understood this back at the start of your reply.

<snip>
> DS

Okay, after a lot of thought and me realizing some mistakes I had made in
interpreting the law and legal precedents I see we are on the same page.

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

cate at debian

Dec 18, 2006, 11:39 PM

Post #171 of 214 (3120 views)
Permalink

Re: GPL only modules [In reply to]

Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>>> In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed. So what? How does this relate with the point above?
>>
>> The binary is a Program, as much as the sources are a Program. Both
>> forms are subject to copyright law and to the license, in spite of
>> http://www.fsfla.org/?q=en/node/128#1
>
> Here's how it relates:
> - if a program is not a "derived work" of the C library, then it's not
> "the program" as defined by the GPLv2 AT ALL.
>
> In other words, it doesn't matter ONE WHIT whether you use "ld --static"
> or "ld" or "mkisofs" - if the program isn't (by copyright law) derived
> from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY
> AFFECT THE RESULTING BINARY.

I really don't agree. It seems you confuse source and binary application.

The source surelly is not derived, you can link *any* libc to your
program.

But a binary is different.

Let start with your example about books: you write a book, you have
the copyright of the text, but if you publish it with X publiher, he
may use a own font. You can read the book, scan it to extract text
(I hope fair use allows it), but not copy the book pages: there is
your text, but also copyrighted font. Publisher should check
that the two license are compatible, as the user that links
with a new library.

For binary, it is the same. You can extract libraries and rest of
programs (better doing with sources), but until it is one binary,
it is a new mixed entity.

It is not only linking, it is mixing bytes! Some part of library is
linked statically, there are some references in the static part of
program. It is a mix and until the two part are mixed (not only linked)
you should follow both licenses for copying!

Choose any dynamic program in your machine, try to link glibc with an
other (not directly derived libc) library... you see how it is hard,
and it is very different to an "aggregation". And dynamic links is
only the latest step of "merging" the two binaries.

Other libraries tend to be more "dynamic", but glibc mixes to much

In other word, source A, library B: the binary C is derived both from A
and B, but surelly A is not derived by B. So IMHO IANAL, in arguments
we should not confuse the sources and the binary in the arguments, so
not calling simply "the program".

ciao
cate

>
> And I'm simply claiming that a binary doesn't become "derived from" by any
> action of linking.
>
> Even if you link using "ld", even if it's static, the binary is not
> "derived from". It's an aggregate.
>
> "Derivation" has nothing to do with "linking". Either it's derived or it
> is not, and "linking" simply doesn't matter. It doesn't matter whether
> it's static or dynamic. That's a detail that simply doesn't have anythign
> at all to do with "derivative work".
>
> THAT is my point.
>
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> static linking aggregates the library with the other program in the same
> binary. There's no question about that. And that _does_ have meaning from
> a copyright law angle, since if you don't have permission to ship
> aggregate works under the license, then you can't ship said binary. It's
> just a non-issue in the specific case of the GPLv2.
>
> In the presense of dynamic linking the binary isn't even an aggregate
> work.
>
> THAT is the difference between static and dynamic. A simple command line
> flag to the linker shouldn't really reasonably be considered to change
> "derivation" status.
>
> Either something is derived, or it's not. If it's derived, "ld",
> "mkisofs", "putting them close together" or "shipping them on totally
> separate CD's" doesn't matter. It's still derived.
>
> Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

cate at debian

Dec 18, 2006, 11:40 PM

Post #172 of 214 (3123 views)
Permalink

Re: GPL only modules [In reply to]

sanjoy at mrao

Dec 19, 2006, 12:00 AM

Post #173 of 214 (3124 views)
Permalink

Re: GPL only modules [In reply to]

Linus Torvalds wrote:
> That said, I think they are still pushing the "you don't have any
> rights unless we give you additional rights explicitly" angle a bit
> too hard.

From section 2 (GPLv3, draft 2):

This License acknowledges your rights of "fair use" or other
equivalent, as provided by copyright law.

By choosing 'acknowledges' as the verb, the licensee says explicitly
that fair-use rights are already yours, not that they are being given
to you.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

vonbrand at inf

Dec 19, 2006, 4:42 AM

Post #174 of 214 (3118 views)
Permalink

Re: GPL only modules [In reply to]

D. Hazelton <dhazelton[at]enter.net> wrote:

[...]

> The GPL is a License that covers how the code may be used, modified and
> distributed. This is the reason that the FSF people had to make the big
> exception for Bison, because the parser skeleton is such an integral part of
> Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the
> program) that truthfully, any parser built using Bison is a derivative work
> of code released under the GPL.

They didn't "have to make the big exception", if Linus' view is correct:
The parser is built mechanically from the skeleton and the user's input, so
it is just an aggregation. Sure, it is best to make this clear (by the
exception), even if not needed.

> That said, since there is a distribution, use and modification license on
> the Linux Kernel - the GPLv2 - there are those extra restrictions on the
> code *OUTSIDE* the copyright rules.

A license like GPL works /inside/ copyright law, by allowing you to do
things the law prohibits unless the owner of the right agrees. What the law
allows explicitly, regardless of the owner's wishes, can't be taken away.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

marekw1977 at yahoo

Dec 19, 2006, 4:57 AM

Post #175 of 214 (3119 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> Since `works with' may sound a bit too vague, something like
> `LinuxFriendly(tm)', with a happy penguin logo?

It would be really cool to see penguin logos on hardware :)

I had another, probably crazy idea. Would it be possible to utilize the
current vendor/device PCI ID database to create Linux friendliness matrix
site?

And if you let yourself get carried away, you can also imagine a little
multi-platform utility. It would run on a test system collecting PCI IDs
before submitting them to the site to get the system's overall Linux
friendliness rating.

In cases where the system contains devices which do not have entries in the
database, the system could look up and use the vendor's Linux friendliness
rating.

Something like that could really help end users to select the right system and
would reward those who do the right thing.

Cheers,

Marek Wawrzyczny
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3 4 5 6 7 8 9

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com