Re: Fwd: That whole "Linux stealing our code" thing

2007-09-04 Thread Michael Poole
Chris Friesen writes:

> Daniel Hazelton wrote:
>> On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote:
>>
>>>Daniel Hazelton <[EMAIL PROTECTED]> writes:
>>>
US Copyright law. A copyright holder, regardless of what license he/she
may have released the work under, can still revoke the license for a
specific person or group of people. (There are some exceptions, but they
do not apply to the situation that is being discussed)
>
> The OpenBSD policy page doesn't agree with you:
>
> "...That means that having granted a permission, the copyright holder
> can not retroactively say that an individual or class of individuals
> are no longer granted those permissions. Likewise should the copyright
> holder decide to "go commercial" he can not revoke permissions already
> granted for the use of the work as distributed, though he may impose
> more restrictive permissions in his future distributions of that work."
>
> http://www.openbsd.org/policy.html

By my reading, this is supported by 17 USC 203(a)(3):

  (3) Termination of the grant may be effected at any time during a
  period of five years beginning at the end of thirty-five years
  from the date of execution of the grant; or, if the grant covers
  the right of publication of the work, the period begins at the
  end of thirty-five years from the date of publication of the
  work under the grant or at the end of forty years from the date
  of execution of the grant, whichever term ends earlier.

(from 
http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0203000-.html
 )

I would be interested to see what other legal basis is alleged as
grounds to rescind a license.

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


Re: Noatime vs relatime

2007-08-10 Thread Michael Poole
Vlad writes:

> Relatime seems to be wasteful of both IO resources _and_ CPU cycles.
> Instead of performing a single IO operation (as atime does), relatime
> performs at least three IO operations and three CPU-dependent
> operations:
>
> 1) a read IO operation to find out the old atime
> 2) a read IO operation to find out the old ctime
> 3) a read IO operation to find out the old mtime
> 4) Comparison of "old atime is <= than mtime/ctime"
> 5) Find out current time
> 6) Comparison of "current time minus old atime is > X"
>
> People are going to wonder why all of the sudden everything is running
> so slow due to atimes being updated after a long break.

Filesystems deal with block devices, which have fairly large (at least
512-byte) read and write granularity.  Sane filesystems have atime,
ctime and mtime all in the same block, so one read gets all three.
The file's metadata would be in the cache while it's open anyway.

CPU operations are many orders of magnitude faster than block I/O, so
if steps 4-6 eliminate even a fraction of a percent of atime
writebacks, relatime is a net benefit.  In practice, most files are
read many more times than they are written, and most of those are
eliminated even with step #6.  Academic journals abound with
storage-related studies of read versus write patterns (often including
temporal locality of reference) for various kinds of files; I refer
you to those for details.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
[EMAIL PROTECTED] writes:

> On Wed, 20 Jun 2007, Michael Poole wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>> if the GPL can excercise control over compilations, then if Oracle
>>> were to ship a Oracle Linux live CD that contained the Oracle Database
>>> in the filesystem image, ready to run. then the GPL would be able to
>>> control the Oracle Database code.
>>
>> By copyright law, it could.  By its language, it does not.
>
> many people (including many lawyers will disagree that it could by
> copyright law

On what grounds would Oracle have a license to ship that part of
Linux?  Unless you are the sole copyright owner, you have no right to
copy a given piece of software _at all_ without a license.  The GPL is
a remarkably giving license in terms of how little it requires.

(This potentially wide scope is one of the major reasons that the GPL
mentions "mere aggregation" and that the Debian Free Software
Guidelines' include guideline #9.)

>>> if the GPL can't do this then it can't control the checksum either.
>>>
>>> again, it's not just the kernel that's part of the checksum on a tivo,
>>> the checksum is over the kernel + initial filesystem, much of which
>>> contains code not covered by the gPL)
>>
>> Again, did you miss where I pointed out that this makes it *worse* for
>> Tivo, because they are tying together -- and making inseparable -- a
>> combination that would otherwise be "mere aggregation"?
>
> and it makes most distro CD's illegal since they contain code under
> different incompatible licenses and they make a checksum across the
> entire CD image.

When distributions generate checksums (as opposed to signatures) over
images, they do provide all of the inputs.  When most distributions
provide signatures, the signatures do not function as statements or
instructions to computers -- they function as statements to users.
Tivo's digital signatures differ in both of these respects.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
[EMAIL PROTECTED] writes:

> if the GPL can excercise control over compilations, then if Oracle
> were to ship a Oracle Linux live CD that contained the Oracle Database
> in the filesystem image, ready to run. then the GPL would be able to
> control the Oracle Database code.

By copyright law, it could.  By its language, it does not.

> if the GPL can't do this then it can't control the checksum either.
>
> again, it's not just the kernel that's part of the checksum on a tivo,
> the checksum is over the kernel + initial filesystem, much of which
> contains code not covered by the gPL)

Again, did you miss where I pointed out that this makes it *worse* for
Tivo, because they are tying together -- and making inseparable -- a
combination that would otherwise be "mere aggregation"?

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
David Schwartz writes:

>> There is a lot of grey and/or arguable area about what constitutes a
>> GPL-encumbered collective work versus mere aggregation.
>
> I think it's technically/legally clear what the standards are, but certainly
> arguable whether particular works meet that standard. If the choice of works
> to combine is sufficiently creative (above and beyond any choices dictated
> by functional considerations), it's a GPL-encumbered collective work.
>
> I don't think it's arguable that a signature shipped along with a binary is
> a collective work. In any event, if that were true, I think we should be
> able to agree that Linus would be required to release his kernel signing
> keys.

The distinction between GPL-covered works and "mere aggregation" is
not a function only of legal classifications.  If it were, the GPL
would be worded differently than it is -- and have different effects
than most people believe it does.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
David Schwartz writes:

>> However, compilations (even to the extent they are creative
>> combinations) are not necessarily derivative works of their elements.
>> For more details, see
>> http://www.copyright.gov/circs/circ14.html#compilations
>
> Because compilation copyrights don't really affect the Tivo and GPLv2/GPLv3
> issue, I tend to ignore them when discussing that subject. If you think I'm
> wrong and there is some relationship between them, please let me know. I
> admit I may not have given that possibility enough thought.

I believe compilation copyrights do bear on GPL-licensed software, by
virtue of the GPL's sentence "[...] rather, the intent is to exercise
the right to control the distribution of derivative _or collective_
works based on the Program." (emphasis added).

There is a lot of grey and/or arguable area about what constitutes a
GPL-encumbered collective work versus mere aggregation.  Although I
disagree, I understand and respect that some believe that the kernel
plus a digital signature over it is "mere aggregation".  I would like
to focus the discussion on that question, though, rather than whether
the GPL is worded to control the rights to compilations-in-general
that include GPLed works.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
David Schwartz writes:

>> Most of this list has
>> already dismissed your rather unique -- I would even say frivolous --
>> idea of how far "mere aggregation" goes: I, for one, have better
>> things to do than explain why a C file is not a "mere aggregation" of
>> the functions it contains.)
>>
>> Michael Poole
>
> Of course it's not mere aggregation. The functions in a C file are
> creatively combined. How many times do I have to say that the opposite of
> "mere aggregation" is creative combination?
>
> It is not unique, it is part of the definition of a "derivative work".

By "creative combination" do you mean what US copyright law refers to
as compilations (or their subset collective works)?

Compilations can be creative combinations while still being mere
aggregation under the GPL.  For example, if applications are selected
to run with a Linux kernel, and they are distributed together, the
collection is a creative selection -- and this seems to be one of the
cases evoked by the GPL's reference to "mere aggregation".  See also
practically every Linux distribution on the planet.

Compilations also can be creative combinations and *more* than mere
aggregation: for example, Linux with respect to its subsystems, or any
case where a larger work is derivative of one of its components.

However, compilations (even to the extent they are creative
combinations) are not necessarily derivative works of their elements.
For more details, see
http://www.copyright.gov/circs/circ14.html#compilations

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
David Schwartz writes:

>> I do not say that the BIOS is doing anything (legally) wrong.  The
>> wrong act is distributing the binary kernel image without distributing
>> complete source code for it.
>
> Why are you not complaining that Linus does not distribute the keys he uses
> to sign kernel source distributions? If a digital signature is part of the
> distribution, why is the key used to produce that signature not part of the
> distribution?
>
> If you can cite some legal reason there is a difference, I would be quite
> impressed.
>
> In any event, the argument is obvious nonsense. The signature is merely
> aggregated with the kernel. Cooperation, dependent function, and convergent
> design can't break mere aggregation or you get ridiculous results. (For
> example, a device shipped with the Linux kernel and some applications would
> have to GPL all the applications.)

Do you make it a habit to pose ranty questions to people while neither
attributing their text nor cc'ing them?  Especially when you claim the
person's argument is "obvious nonsense", it seems quite rude.

(Since you have dismissed my argument as nonsense before hearing my
response, I will not bother answering your question.  Since you are
acting like a troll, I will dismiss you as one.  Most of this list has
already dismissed your rather unique -- I would even say frivolous --
idea of how far "mere aggregation" goes: I, for one, have better
things to do than explain why a C file is not a "mere aggregation" of
the functions it contains.)

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
Tomas Neme writes:

>> A "computer program" is a set of statements or instructions to be
>> used directly or indirectly in a computer in order to bring about
>> a certain result.
>> -- US Code, Title 17, Section 101
>
> so?

People keep arguing that the signature is somehow not part of the
kernel or not subject to copyright law.  I suspect they do not realize
how broad the legal definition of "computer program" is.

> Not GPL related, but casino machine software that needs to be approved
> by the casino regulation office in Argentina need to provide source,
> compiling instructions AND binaries, and the binaries must pass a diff
> check. This is impossible without a hacked compiler since the
> timestamps WILL differ.
>
> Just an example that legality doesn't always comply with itself, and
> even less make sense.

This discussion is about copyright and the GPL, not legal quirks.  I
am aware of a large number of silly results reached by law.

> plus, and I repeat myself.. the program comes with no warranties whatsoever.
>
> and if your complains are purely moral, see it this way: if TiVo
> didn't sign their kernel, digital cable providers wouldn't give them
> their hash keys, and they wouldn't be able to show HD signals,
> rendering them useless, and making them go bankrupt... so they'd go
> BSD, because they ARE a company after all, and they are after The
> Moneys..
>
> no?

The GPL does not guarantee anyone a viable business model.  Following
it is not conditional on profitability.  It is only conditional on
exercising rights that are granted by the GPL.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
[EMAIL PROTECTED] writes:

> On Wed, 20 Jun 2007, Michael Poole wrote:
>
>> Please retract that claim.  I have said no such thing, and have
>> avoided saying anything that I thought might be misconstrued in that
>> direction.
>>
>> To be absolutely clear: My complaints with Tivo as a hardware or BIOS
>> vendor are moral and pragmatic, not legal.  My complaint with Tivo as
>> a distributor of Linux is what hinges on legal issues.
>
> but if the GPL doesn't control the BIOS how in the world are you
> saying that the fact that the GPL covers the kernel makes what the
> BIOS does wrong (even if the kernel was covered by GPLv3)?

I do not say that the BIOS is doing anything (legally) wrong.  The
wrong act is distributing the binary kernel image without distributing
complete source code for it.

>>> that's a seperate body of code that is in no way derived from the
>>> linux kernel (even the anti-tampering functions would work equally
>>> well with other Operating systems and are in no way linux
>>> specific). it's no even loaded on the same media (the BIOS is in
>>> flash/rom on the botherboard, the OS is on the hard drive)
>>>
>>> and note that the software that is checked to make sure that it hasn't
>>> been changed includes much more then the kernel. it checks the kernel
>>> and the initrd.
>>
>> Not legally relevant.
>
> I disagree. it's very relevant if your argument is that becouse the
> checksum if a checksum of the kernel that the license for the kernel
> somehow controlls what can be done with it.

To the extent that it is relevant, it strengthens the argument against
Tivo: they are tying together many works of authorship, including some
GPLed works, in a way that makes them effectively inseparable.  This
is beyond "mere aggregation" on a distribution medium, and tends to
implicate *all* parts of the whole as GPL encumbered.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
[EMAIL PROTECTED] writes:

> On Wed, 20 Jun 2007, Michael Poole wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>> no, saying that the result must be acceptable to other software (in
>>> this case the software running in the BIOS) is not part of the source
>>> code.
>>
>> Why not?  The digital signature is a statement (which translates
>> roughly to "Tivo approves this") to be used in a computer in order to
>> bring about a certain result.  That result is making it boot on the
>> PVR.  Source code simply means the original forms or inputs used to
>> generate machine-readable statements.
>
> but the signature isn't part of the kernel, and the code that checks
> the signature is completely independant. and finally the PVR functions
> are not part of the kernel (and not under the GPL in any case)
>
> if your argument was true then Oracle releasing a database appliance
> would require Oracle to give you the source to their database since
> it's part of 'bringing about a certain result' namely operating as a
> database server.

>From the kernel's COPYING file:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".

See also the portion below.

> if your argument was true then releasing a GPL package for windows
> would require that the windows kernel source be released, after it
> it's nessasary for 'brining about a certain result' namely letting
> your code run.

>From section 3 of the GPL:

  However, as a special exception, the source code distributed need
  not include anything that is normally distributed (in either source
  or binary form) with the major components (compiler, kernel, and so
  on) of the operating system on which the executable runs, unless
  that component itself accompanies the executable.

> these are both nonsense results.

.. which is why they are recognized to be different.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
[EMAIL PROTECTED] writes:

> On Wed, 20 Jun 2007, Michael Poole wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>> this is very much NOT true. if you take the source the provide you can
>>> compile a kernel that will run on the tivo, the only thing you have to
>>> do (on some models) is to change the bios to skip the step that checks
>>> if the kernel has been tampered with.
>>
>> If we are opining whether Tivo provided complete source code for their
>> Linux kernel images, the requirement to change non-GPLed software as a
>> condition to exercise GPL-protected rights speaks for itself.
>
> no, the GPL protected rights don't say anything about the hardware the
> system runs on.
>
> you are saying that the GPL now controls what the BIOS software is
> allowed to do or not allowed to do.

Please retract that claim.  I have said no such thing, and have
avoided saying anything that I thought might be misconstrued in that
direction.

To be absolutely clear: My complaints with Tivo as a hardware or BIOS
vendor are moral and pragmatic, not legal.  My complaint with Tivo as
a distributor of Linux is what hinges on legal issues.

> that's a seperate body of code that is in no way derived from the
> linux kernel (even the anti-tampering functions would work equally
> well with other Operating systems and are in no way linux
> specific). it's no even loaded on the same media (the BIOS is in
> flash/rom on the botherboard, the OS is on the hard drive)
>
> and note that the software that is checked to make sure that it hasn't
> been changed includes much more then the kernel. it checks the kernel
> and the initrd.

Not legally relevant.

>> Out of curiosity, what do you have to do on models besides those?  Are
>> newer models more or less restrictive in what they run?  If newer
>> models are more restrictive, I think that also speaks to whether Tivo
>> thinks it is conveying complete source code.
>
> newer models do tend to be more restrictive, but they also tend to
> connect to more propriatary networks (satellite or cable)

What they connect to is also not relevant.  That imples that because a
vendor has been issued or licensed patents, they are not obliged to
follow the GPL -- that the vendor has other obligations that supercede
the GPL's license claims.  GPL section 7 addresses that situation.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
[EMAIL PROTECTED] writes:

> no, saying that the result must be acceptable to other software (in
> this case the software running in the BIOS) is not part of the source
> code.

Why not?  The digital signature is a statement (which translates
roughly to "Tivo approves this") to be used in a computer in order to
bring about a certain result.  That result is making it boot on the
PVR.  Source code simply means the original forms or inputs used to
generate machine-readable statements.

Michael Poole

>>A "computer program" is a set of statements or instructions to be
>>used directly or indirectly in a computer in order to bring about
>>a certain result.
>>-- US Code, Title 17, Section 101
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
[EMAIL PROTECTED] writes:

> this is very much NOT true. if you take the source the provide you can
> compile a kernel that will run on the tivo, the only thing you have to
> do (on some models) is to change the bios to skip the step that checks
> if the kernel has been tampered with.

If we are opining whether Tivo provided complete source code for their
Linux kernel images, the requirement to change non-GPLed software as a
condition to exercise GPL-protected rights speaks for itself.

Out of curiosity, what do you have to do on models besides those?  Are
newer models more or less restrictive in what they run?  If newer
models are more restrictive, I think that also speaks to whether Tivo
thinks it is conveying complete source code.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
Tomas Neme writes:

>> It's simple: they don't provide _complete_ source code.  They keep the
>> source code for the part of their Linux kernel images that provides
>> the functionality "runs on Tivo DVRs".  The GPL requires that
>
> http://en.wikipedia.org/wiki/Tivoization does not agree that this is
> the problem but rather "TiVo circumvented this goal by making their
> products run programs only if the program's digital signature matches
> those authorised by the manufacturer of the TiVo."
>
> I'm downloading the sources now.. if they compile, then you're lying
> to me, right? Moreover, if I compile them as is, and I can run them on
> a TiVo (let's say upgrading the machine's kernel) then you're even
> more so..

Whether the sources you download from Tivo compile says very little.
It certainly does not mean I am wrong.  I could give you binary for
version A and sources for version B -- and the sources would compile.

The kernel you build from the source code that Tivo distributes must
be accepted by Tivo's hardware without making other modifications (to
Tivo's hardware or bootloader).  If that is possible, I will retract
what I said.  If it is not possible, they are omitting part of the
program's source code:

A "computer program" is a set of statements or instructions to be
used directly or indirectly in a computer in order to bring about
a certain result.
-- US Code, Title 17, Section 101

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-20 Thread Michael Poole
Tomas Neme writes:

> I have been following this discussion for the last week or so, and
> what I haven't been able to figure out is what the hell is the big
> deal with TiVO doing whatever they want to with their stupid design.
> They made a design, they build a machine, they sell it as is, and
> provide source code for GPL'ed software... what's your problem?

It's simple: they don't provide _complete_ source code.  They keep the
source code for the part of their Linux kernel images that provides
the functionality "runs on Tivo DVRs".  The GPL requires that
distributors of binary versions provide complete source code, not just
the parts of source code that are convenient.

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


Re: mea culpa on the meaning of Tivoization

2007-06-19 Thread Michael Poole
Hans-Jürgen Koch writes:

> No. Credible licenses should be simple like physical laws. Newton's law
> is expressed in terms of a single mathematical equation. That's why it's
> still valid, and you still learn it at school although meanwhile people
> know that there are limitations to it.
>
> If you come up with a new version of a license every year, you will only
> weaken it. Please note that quantum mechanics is _not_ such a hole-plugging
> addition to Newton's law. It's a new simple physical law, expressed in terms
> of a single simple mathematical equation that contains the old law as a
> border case. If that were not the case, it would have never been accepted.

This is an excellent example of how engineers tend to mis-analyze
legal issues.  In law, neither simple wording nor interpretation is so
simple or so mechanical as the things engineers prefer to work with.

Take an example: "Thou shalt not kill".  Very clear, but also very
problematic in that it does not address military conquests (which were
apparently approved by that law's drafter), self-defense, or a number
of other cases.

There are always grey areas between what is explicitly addressed and
what is not.  Courts interpret laws and precedent in ways that make
life (and license or contract writing) more unpredictable.  Wishing
otherwise will not make a simple license unambiguous.  If those areas
of ambiguity are exploited enough, the perceived cost of having a hole
will exceed the perceived cost of plugging it.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-18 Thread Michael Poole
David Schwartz writes:

>> David Schwartz writes:
>
>> >> First, end users buy and use the hardware in question.  It does not
>> >> belong to Tivo, so the analogy to his laptop fails there.
>
>> > No, this is incorrect. They buy *some* of the rights to the
>> > hardware but not
>> > all of them. Specifically, they do not buy the right to choose
>> > what software
>> > runs on that hardware. That right is still owned by TiVo.
>
>> Do you have a reference to the contract establishing that cession of
>> rights from the buyer to Tivo?
>
> No, and I submit that this is at least arguably something wrong that TiVo is
> doing. Note that Microsoft does this too when you buy an Xbox. It has
> nothing to do with the GPL.

There is a significant difference between what is a legally recognized
right and what no one has litigated over.  I tend to not recognize the
latter as the former until I see specific backing for the idea that
the purported right has been recognized by law, a court, or all
involved parties.

>> To the extent that some contract
>> purports to restrict the user in ways contrary to the GPL, I suspect
>> Tivo might have a hard time defending it in court.
>
> I agree, however, this doesn't restrict the user in ways contrary to the
> GPL. The GPL does not say that you have to be allowed to modify the Linux
> running on some particular piece of hardware because that is a legitimate
> authorization decision. TiVo not letting you change the software is the same
> as me not letting you change the software on my laptop.

I disagree that the two are the same -- for the fundamental reason
that you have not distributed the software on your laptop to me.  Tivo
has distributed the software on Tivo DVRs to their customers.  The act
of distribution is governed by (in the case of Linux) copyright law
and the GPL.

>> > You can argue that TiVo is being dishonest, breaking the law,
>> > being immoral,
>> > or whatever in retaining this right or in failing to disclose that they
>> > retain it. But you cannot coherently deny that TiVo retains
>> > this right when
>> > they sell certain other rights to the hardware.
>
>> By the first sale doctrine, someone who buys an item has practically
>> unlimited rights to deal with it or dispose of it as the buyer wishes.
>
> This is solely a right against copyright claims. You would be correct if
> TiVo were going to sue you for violating some copyright they hold in the
> hardware or software if you modified the software.

Do you propose that Tivo would (or could) sue a customer for some
non-copyright tort if the customer were to run a Linux kernel that has
not been authorized by Tivo on a Tivo-manufactured DVR?  As far as I
can tell, the legal concerns in question are all copyright issues.

>> The only things that would restrict that are statute or a contract
>> entered as part of the sale -- most likely a EULA or other shrink-wrap
>> agreement.  Given that most such recognized agreements deal with
>> software or services rather than hardware, I am not sure a court would
>> recognize a hardware EULA as being binding.  (I suspect this is the
>> direction you were heading with the paragraph below.)
>
> Yep, but that has nothing whatsoever to do with the GPL. The exact same
> argument applies with the Xbox. It's about whether authorization to modify a
> device should or must come with buying that device.
>
> The GPL was never about allowing you to load modified software onto hardware
> where the legitimate creators/owners of that hardware say, "no, you may not
> modify the software running on this hardware".

True.  The GPL always about allowing someone to modify software that
they received from someone else.  Tivo's Linux kernel images qualify
both as softare that they distribute to others and software that is
loaded onto hardware that they created.  The concern at hand is not
about hardware that Tivo owns or software that Tivo never distributes
-- except where it is also source code for software that they *do*
distribute.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-18 Thread Michael Poole
David Schwartz writes:

>> First, end users buy and use the hardware in question.  It does not
>> belong to Tivo, so the analogy to his laptop fails there.
>
> No, this is incorrect. They buy *some* of the rights to the hardware but not
> all of them. Specifically, they do not buy the right to choose what software
> runs on that hardware. That right is still owned by TiVo.

Do you have a reference to the contract establishing that cession of
rights from the buyer to Tivo?  To the extent that some contract
purports to restrict the user in ways contrary to the GPL, I suspect
Tivo might have a hard time defending it in court.

> You can argue that TiVo is being dishonest, breaking the law, being immoral,
> or whatever in retaining this right or in failing to disclose that they
> retain it. But you cannot coherently deny that TiVo retains this right when
> they sell certain other rights to the hardware.

By the first sale doctrine, someone who buys an item has practically
unlimited rights to deal with it or dispose of it as the buyer wishes.
The only things that would restrict that are statute or a contract
entered as part of the sale -- most likely a EULA or other shrink-wrap
agreement.  Given that most such recognized agreements deal with
software or services rather than hardware, I am not sure a court would
recognize a hardware EULA as being binding.  (I suspect this is the
direction you were heading with the paragraph below.)

Michael Poole

> I do in fact argue that there are things that are wrong with TiVo doing
> this. But they are not GPL-related things. I would make these same arguments
> if the TiVo contained no GPL'd software and I in fact do make them about
> products like the Xbox.
>
> DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-18 Thread Michael Poole
[EMAIL PROTECTED] writes:

> On Mon, 18 Jun 2007, Alexandre Oliva wrote:
>
>> On Jun 18, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>>
>>>>> Sure, and you use the hardware to stop me from modifying the
>>>>> Linux on your
>>>>> laptop.
>>
>>>> Do I?  How so?
>>
>>> Any number of ways. For example, you probably don't connect the serial ports
>>> to a device I have access to.
>>
>> But you're not the user of the software on my laptop.  I am.
>
> ahh, but by your own argument you aren't
>
> the software on your laptop is owned by people like Linus, Al Viro,
> David M, Alan Cox, etc.

To be pedantic, the *copyrights* for certain software on his laptop
are owned by those people.  (Fortunately, they have been friendly
enough to engage in software quid-pro-quo with those rights.)

> they have the right to put a license on that software that would
> require you to give them access to your hardware (after all, that's
> the argument that you are useing to justify requireing Tivo to give
> you access to their hardware)

Even as straw men go, that is pretty incoherent.

First, end users buy and use the hardware in question.  It does not
belong to Tivo, so the analogy to his laptop fails there.

Second, the important access is not to the hardware, but to the bits
used to build the version of Linux that is distributed by Tivo.  This
is purely software.

Third, such a license would be neither a free software nor an open
source license.  No one argues it would be.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-17 Thread Michael Poole
Daniel Hazelton writes:

> Okay. So they give everyone the right to change the software on the box, but 
> on connection replace the modified stuff with the official versions. Is that 
> still a copyright problem? Absolutely, positively no. Is the current 
> situation any different? Not that I can tell - they've changed a reaction 
> into a preemptive act.

Again, it would be useful to limit discussions to this universe rather
than one that contains fictions necessary to your religious views.

(Separately, hardware connecting to Tivo's network is hardly related
to why they have DRM at all, and _entirely_ unrelated to what the GPL
permits; basing your argument on that nexus is stupid, but you have
obviously given up on your previous idea that the signature is somehow
an independent work of authorship and need some -- any -- theory to
continue holding to your general faith.)

>> > Nope. Because that isn't a right they have that is disconnected from
>> > copyright law. Or did you not read the entire post and just decide to try
>> > and make me look stupid?
>>
>> I read your post, but it was full of nonsense.  Tivo has every right
>> to restrict what connects to their network.  Tivo does not have the
>> right to infringe copyrights in order to make that restriction
>> effective.
>
> Okay - "nonsense" in this sense meaning "it proves me wrong, but I can't be 
> wrong, so it has no real meaning." I can accept that.

No; it means your position is at odds to fact, law and logic.  The
rest of my paragraph summarized why your argument is garbage.

Have you ever heard of the lawyer joke that if law is on your side,
you should pound the law; that if fact is on your side, you should
pound the facts; and that if neither are on your side, you should
pound the table?  You seem to be in the third state.

You suggested that Tivo's right to set terms for their network gave
them the right to modify the Linux kernel.  I twice pointed out in my
email that it did not -- that only the GPL gives them that right.  Any
right to modify the Linux kernel is inherently connected to copyright.
Kindly either refute or acknowledge that point: then this discussion
can advance.

>> You have said -- using enough words that you probably deceived
>> yourself -- that if Tivo distributes a specially mangled version of
>> Linux in order to restrict what connects to their network, and they
>> keep the mangling method proprietary, the GPL cannot shed light on
>> whether that hoarding is allowed.  Wrong: it can and does.
>
> But the mangling method isn't proprietary. What is proprietary is a number 
> that is input to a step of the process. (AFAICT the signing process is done 
> with proprietary tools, but the process itself isn't)

That does not help them at all.  In fact, it is probably *worse* for
Tivo if they are intentionally withholding input to a tool, since that
is closer to the traditional idea of source code.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-17 Thread Michael Poole
Daniel Hazelton writes:

> On Sunday 17 June 2007 09:54:39 Michael Poole wrote:
>> Daniel Hazelton writes:
>> > But your server doesn't run the internet. TiVO may use phone lines to
>> > connect a device to their server (and this is an example - I don't know
>> > how TiVO devices actually connect) but the network being connected to has
>> > a single owner who can set such terms.
>> >
>> > I'll repeat, in full, my earlier examples of this:
>> > The first:
>> > I buy a cable modem. Until the second I connect the cable-line to it so I
>> > can get a connection to the internet I can configure it in whatever
>> > manner I please. The second the line is connected, even though I *OWN*
>> > the hardware, I lose all control over its configuration.
>> >
>> > The second:
>> > I buy a DSL modem. Until I want to actually connect to the internet it
>> > can have whatever settings I want it to have. The second I want to
>> > connect to the internet it has to be configured the way that the ISP
>> > wants.
>>
>> Jung va gur jbeyq znxrf lbh guvax gurer vf n hfrshy nanybtl
>> orgjrra pbzzhavpngvba fgnaqneqf naq pbclevtug yvprafrf?
>>
>> One moment, let me retune.
>>
>> What in the world makes you think there is a useful analogy
>> between communication standards and copyright licenses?
>
> I don't. I was *REPEATING* an example of how TiVO has a *RIGHT* to change the 
> kernel or any other facet of the device connecting to their network. That 
> right *ISN'T* tied to copyright - as you have stated. Since it isn't, why is 
> the FSF trying to mandate that it is with the tivoization clauses in GPLv3?

The FSF *ISN'T* trying to mandate what *CONNECTS* to *TiVO's*
*NETWORK*.  *BOY* *ISN'T* *SHOUTING* *FUN*?  If Tivo wants to restrict
what connects to their network, the GPL and FSF will not stop them.
The major new (relative to GPLv2) things the FSF is trying to restrict
are new technical and legal methods that software distributors have
tried to use to convert free software into non-free software.

Tivo's right to dictate or change aspects of devices connecting to
their network is very much tied to copyright: Tivo needs appropriate
license if they are modifying or distributing anyone else's work.  I
am not sure why you think Tivo's right to free association trumps its
freely entered obligations to copyright owners.

>> Neither law nor common sense give much common ground to the two,
>> except in the general sense of two parties interacting.  One is a set
>> of rules so the two can interact through some information channel.
>> The other is a set of rules so that one can exploit a creative work
>> developed by the other.
>>
>> I suppose that you think it is acceptable for someone to offer access
>> to binary and source versions of GPLed software (with or without
>> modifications from commonly available versions) -- but only on the
>> condition that people never download the source versions?  That
>> certainly corresponds to the idea that Tivo can keep proprietary
>> extensions to the kernel if Tivo's customers want to connect to Tivo's
>> network services.
>
> Nope. Because that isn't a right they have that is disconnected from 
> copyright 
> law. Or did you not read the entire post and just decide to try and make me 
> look stupid?

I read your post, but it was full of nonsense.  Tivo has every right
to restrict what connects to their network.  Tivo does not have the
right to infringe copyrights in order to make that restriction
effective.

You have said -- using enough words that you probably deceived
yourself -- that if Tivo distributes a specially mangled version of
Linux in order to restrict what connects to their network, and they
keep the mangling method proprietary, the GPL cannot shed light on
whether that hoarding is allowed.  Wrong: it can and does.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-17 Thread Michael Poole
Daniel Hazelton writes:

> But your server doesn't run the internet. TiVO may use phone lines to connect 
> a device to their server (and this is an example - I don't know how TiVO 
> devices actually connect) but the network being connected to has a single 
> owner who can set such terms. 
> 
> I'll repeat, in full, my earlier examples of this:
> The first:
> I buy a cable modem. Until the second I connect the cable-line to it so I can 
> get a connection to the internet I can configure it in whatever manner I 
> please. The second the line is connected, even though I *OWN* the hardware, I 
> lose all control over its configuration.
>
> The second:
> I buy a DSL modem. Until I want to actually connect to the internet it can 
> have whatever settings I want it to have. The second I want to connect to the 
> internet it has to be configured the way that the ISP wants.

Jung va gur jbeyq znxrf lbh guvax gurer vf n hfrshy nanybtl
orgjrra pbzzhavpngvba fgnaqneqf naq pbclevtug yvprafrf?

One moment, let me retune.

What in the world makes you think there is a useful analogy
between communication standards and copyright licenses?

Neither law nor common sense give much common ground to the two,
except in the general sense of two parties interacting.  One is a set
of rules so the two can interact through some information channel.
The other is a set of rules so that one can exploit a creative work
developed by the other.

I suppose that you think it is acceptable for someone to offer access
to binary and source versions of GPLed software (with or without
modifications from commonly available versions) -- but only on the
condition that people never download the source versions?  That
certainly corresponds to the idea that Tivo can keep proprietary
extensions to the kernel if Tivo's customers want to connect to Tivo's
network services.

Your reliance on counterfactual arguments severely undermines your
position -- whether the fiction is how Tivo devices connect (a quick
search on Google indicates that Tivo recommends a broadband Ethernet
connection rather than a phone line) or that we should analyze based
on DRM signatures distributed separately from the kernel (when they
are not).  We are arguing about the universe we inhabit, not some
alternative where the GPL might actually be the Groundhog Petting
License.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-17 Thread Michael Poole
Ingo Molnar writes:

> * Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>
>> On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> 
>> > it is a false statement on your part that the executable "does not 
>> > function properly" if it lacks that part. Try it: take out the harddisk 
>> > from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux 
>> > PC, mount it, modify a bit in the kernel image header and it will likely 
>> > still boot just fine on that PC.
>> 
>> Ok, try this: take the disk out, remove/replace/modify the signature, 
>> put the disk back in, and tell me what it is that fail to run.
>
> you mean back into the Tivo? That is not support for what you claimed. 
> You claimed the "executable does not function properly" if it lacks that 
> part (and you did not qualify your statement with anything). That was a 
> false statement, because it still works fine in just about any 
> bog-standard PC. A true statement would be: "the modified executable 
> does not function properly _in the Tivo_". It still works fine on a 
> general purpose PC.

I claimed that.  Unless I missed something, Alexandre did not.

Ability to run on a standard PC is irrelevant.  Tivo distributes the
executable for the specific purpose of running on their hardware.
Having the signature accepted by the hardware is a critical aspect of
the executable.  That purpose and function are what make the signature
part of the work based on Linux.

Courts consider purpose and intent when analyzing actions; except when
one has bought the best available legal system, they would not follow
your logic.  (The role the signature plays in controlling access to a
copyrighted work, per DMCA, might also separately identify it as part
of the work based on Linux.)

If I wished to distribute a kernel with extended functionality from a
C file but not the C source files, under your logic I need not give
them out -- a user could modify the binary and run it on a general
purpose PC.  Right?  At most it would take clever linker tricks to
make the change small enough.

As to the suggestion that vendors would use another kernel: I would
not mind.  A huge fraction of the interesting and useful work in open
source kernels happens in Linux (first or only).  Using any third
party software is a trade-off of what you get versus what you give up.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-15 Thread Michael Poole
Florin Malita writes:

> On 06/15/2007 12:18 PM, Michael Poole wrote:
>> Florin Malita writes:
>>
>>   
>>> On 06/15/2007 10:56 AM, Michael Poole wrote:
>>> 
>>>> The GPL cares about the key
>>>> used to generate an integral part of the executable form of the GPLed
>>>> work.
>>> GLPv2 doesn't: why do you think the digital signature is an integral
>>> part of the executable? It can be a totally separate blob, distributed
>>> via a separate channel and even stored at a different location than
>>> the executable. Does it still look like an integral part of the
>>> executable to you then?
>>> 
>>
>> Yes.  If I cut a book in half and store the halves separately, does
>> the second half become an independent work?  
>
> Except in this case you're not touching the book at all. If you write
> a review for a book (much better analogy methinks), then your review
> is obviously not an integral part of the book even though it's based
> on its content.

Extremely poor analogy.  I do not distribute my review with the book.
Someone buying the book is able to use the book just fine (for the
purpose for which it was sold) without my review.  They need neither
my review nor other modifications before the book becomes readable.
As Ingo said, you need either the digital signature or other changes
before a Tivo kernel image will load.

>> The integral-ness is a
>> function of how the thing is created and how it functions, not how it
>> is stored.  If you need part B for part A to execute as intended, then
>> part A is not a complete work in itself.
>
> Being an integral part (as in combined or derived work) has nothing to
> do with usability. There are many other bits and pieces your
> executable needs in order to function properly (or at all) but that
> doesn't make your CPU microcode & electricity provider an integral
> part of the program, does it?

No.  Those are independent works.  They are not distributed to make a
certain piece of software function in a particular way or place.  The
presence of software in a box with CPU microcode is -- at least in
every case I have seen -- what GPL calls "mere aggregation".

> Luckily, it doesn't really matter what you or I think that
> "integral-ness" means, all it matters is how copyright law defines a
> "derivative work" and whether a cryptographic hash is such a
> thing. Now are you seriously arguing that a hash is a derivative work?

No.  I explained this before.  Try reading the thread and the GPL.  I
am not sure where people get the (wrong) idea that the GPL only
concerns itself with "derivative work[s]".

>>   On top of this, in the Tivo
>> case the two are distributed together, and even part of the same file.
>>   
>
> It's mere aggregation, but it's totally irrelevant because they could
> just as easily change their approach.

If and when they do, I'll consider the rules that might apply.  Until
then, it is fairly stupid to try to defend Tivo by saying they *might*
do something they currently don't, and if they did, they *might* have
a defense that they currently don't.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-15 Thread Michael Poole
Florin Malita writes:

> On 06/15/2007 10:56 AM, Michael Poole wrote:
>> The GPL cares about the key
>> used to generate an integral part of the executable form of the GPLed
>> work.  
>
> GLPv2 doesn't: why do you think the digital signature is an integral
> part of the executable? It can be a totally separate blob, distributed
> via a separate channel and even stored at a different location than
> the executable. Does it still look like an integral part of the
> executable to you then?

Yes.  If I cut a book in half and store the halves separately, does
the second half become an independent work?  The integral-ness is a
function of how the thing is created and how it functions, not how it
is stored.  If you need part B for part A to execute as intended, then
part A is not a complete work in itself.  On top of this, in the Tivo
case the two are distributed together, and even part of the same file.

[snip]
> Do you honestly believe GPLv2 requires the distributor to provide you
> with the right environment for your modified copy to "function
> properly"? I would say it doesn't, but feel free to point me to
> specific sections which *state* otherwise. AFAICT, GPLv2 is
> specifically limited to "copying, distribution and modification". How
> you use (or don't use, or can't use) your modified copy is totally
> outside its scope.

The GPL does not require a distributor to provide me with any kind of
environment.  If I get a Tivo kernel image but do not have a Tivo, the
GPL does not require anyone to give me hardware.  Fortunately, that is
not at all my argument.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-15 Thread Michael Poole
Ingo Molnar writes:

> * Michael Poole <[EMAIL PROTECTED]> wrote:
>
>> > I.e. you cannot just cleverly define "source code" to include 
>> > something unrelated and then pretend that it's all in one work. And 
>> > that's exactly what the GPLv3 does: it creatively defines the 
>> > hardware's key into the 'source code' of the software and then asks 
>> > for that to be provided _not_ because somehow the key derives from 
>> > the software (it clearly does not), but as a "compensation" for the 
>> > right to redistribute! I.e. it's trying to extend its scope to some 
>> > item that is not part of the software. See?
>> 
>> No.  The GPL does not care about the hardware's key, as I pointed out 
>> in the part of my email that you cut out.  The GPL cares about the key 
>> used to generate an integral part of the executable form of the GPLed 
>> work.  The executable does not function properly if it lacks that 
>> part. [...]
>
> it is a false statement on your part that the executable "does not 
> function properly" if it lacks that part. Try it: take out the harddisk 
> from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux 
> PC, mount it, modify a bit in the kernel image header and it will likely 
> still boot just fine on that PC.

Tivo did not program or sell the hard drive to be used in an arbitrary
Linux PC.  They sold the hard drive to be used in their hardware, with
a Linux kernel specifically modified for that.  Without the right
digital signature, it does not do the same thing: it is *incomplete*.
That is eminently a software issue.  Hardware limitations -- whether
they be RAM size or requirement for a certain digital signature -- are
beside the point.

The requirement that I "modify a bit in the kernel image header" is
also one of the most pathetic cop-outs I have seen.  What makes that
binary format the preferred form for modification of Linux?

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-15 Thread Michael Poole
Ingo Molnar writes:

> * Michael Poole <[EMAIL PROTECTED]> wrote:
>
>> >> I do not suggest that copyright subsists in the signature or in the 
>> >> signing key.  Whether it does is irrelevant to the signing key 
>> >> being part of the source code (when the signature is needed for the 
>> >> binary to work properly).
>> >
>> > it is very much relevant. By admitting that the key is not part of 
>> > the "work", you have lost all moral basis to claim control over it.
>> 
>> I have not admitted any such thing.  I have said the key and signature 
>> do not have separate copyright protection.  Variables named "i" in a 
>> file are not protected by copyright, but they are very much part of 
>> the source code in that file.
>
> the problem with your argument is that the definition of what 
> constitutes "work" is up to copyright law, _not_ the license writer. 

Linux is unquestionably a work protected under copyright law.  When I
compile Linux, copyright law still protects the executable form.  This
is not a problem.

> I.e. you cannot just cleverly define "source code" to include something 
> unrelated and then pretend that it's all in one work. And that's exactly 
> what the GPLv3 does: it creatively defines the hardware's key into the 
> 'source code' of the software and then asks for that to be provided 
> _not_ because somehow the key derives from the software (it clearly does 
> not), but as a "compensation" for the right to redistribute! I.e. it's 
> trying to extend its scope to some item that is not part of the 
> software. See?

No.  The GPL does not care about the hardware's key, as I pointed out
in the part of my email that you cut out.  The GPL cares about the key
used to generate an integral part of the executable form of the GPLed
work.  The executable does not function properly if it lacks that
part.  This is exactly the same way in which the GPL cares about the
programming instructions in other parts of the source code: if you
remove them, the resulting work does something quite different.  See?

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-15 Thread Michael Poole
Ingo Molnar writes:

> * Michael Poole <[EMAIL PROTECTED]> wrote:
>
>> > However, since the signing is an automated process it cannot 
>> > generate a "new" work - at least, not under the laws of the US - so 
>> > the signature itself cannot have a copyright at all.
> [...]
>> 
>> I do not suggest that copyright subsists in the signature or in the 
>> signing key.  Whether it does is irrelevant to the signing key being 
>> part of the source code (when the signature is needed for the binary 
>> to work properly).
>
> it is very much relevant. By admitting that the key is not part of the 
> "work", you have lost all moral basis to claim control over it.

I have not admitted any such thing.  I have said the key and signature
do not have separate copyright protection.  Variables named "i" in a
file are not protected by copyright, but they are very much part of
the source code in that file.

>> Similarly, copyright might not subsist in a simple linker script -- 
>> its content being determined by the operating system and perhaps the 
>> rest of the program's source code -- but under the GPL, the linker 
>> script would be part of the source code for a compiled version.
>
> the linker script is still part of the whole work though - even if that 
> particular element might not be copyrightable in isolation. Likewise, 
> the kernel contains code that is in the public domain - to which 
> copyright protection does not extend either. But you cannot argue that 
> the Tivo 'key' is part of the whole work. It is part of the _hardware_. 
> The Tivo box is a compilation (at most a collection) of multiple works, 
> and allowing the GPL to jump over derivation/modification lines is 
> wrong. The GPLv2 certain doesnt do that land-grab.

Where in the Tivo hardware is the signing key?  There is a related key
in the hardware, but that one is not used to generate an integral part
of the kernel binary.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-15 Thread Michael Poole
Daniel Hazelton writes:

> On Friday 15 June 2007 05:30:09 Bernd Paysan wrote:
>> On Friday 15 June 2007 01:46, [EMAIL PROTECTED] wrote:
>> > if you cannot modify the software that runs on your Tivo hardware you
>> > haven't tried very hard.
>>
>> Yes, but the GPLv2 clearly says that you don't have to try very hard. The
>> preferred form of modification has to be distributed. I can run a
>> decompiler or disassembler on a program, and I can even modify it in place
>> with a hex editor (I have even modified programs in embedded ROMs by using
>> focussed ion beam, so I know you can modify every program if you try hard
>> enough). It's certainly possible to crack Tivo's firmware to accept my own
>> signature, but it's *not* the preferred form of modification, the source
>> code and Tivo's key for the signature.
>
> How is a signing key part of the "preferred form for modification"? It isn't 
> a 
> requirement to *modify* anything, just to *replace* something. (And I am 
> *NOT* going to explain why "replace != modify" again)

The signing key determines a critical portion of the binary form that
was distributed.  You cannot produce that portion of the binary form
without the signing key.  Without that portion, the binary form does
not perform the function for which it is distributed.  If you think
such an input is not part of "the preferred form for modification", I
have a bridge to sell you.

The work that the GPL protects a recipient's right to modify and
redistribute is not the source code -- it is each form the user
receives.

>> Since Tivo's firmware only accepts a signed kernel, the combination of
>> kernel+signature is the binary they ship. The kernel itself is useless, the
>> signature as well. Therefore, you can imply that Tivo's key is part of
>> the "other stuff" the GPLv2 mentions, because you need it to recreate the
>> same code as Tivo did and shipped (compilers insert timestamps and such),
>> and to modify that code. The source code is just a mean, the thing they
>> shipped is the end (the binary), and they have to comply with the GPL for
>> that binary - which by all means of practical understanding includes the
>> signature.
>
> I can find no such requirement in the GPLv2. In fact, it actually says that 
> you don't even have to be able to *USE* the program. See section 12 of the 
> GPL if you don't believe me.

Section 12 of the GPL(v2) is a warranty and liability disclaimer.  It
is not an absolution of license obligations.  It limits the liability
of a distributor to the end user, not to copyright owners.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-15 Thread Michael Poole
Daniel Hazelton writes:

> Following your logic it would be a "failure to distribute the source code for 
> a work".
>
> However, since the signing is an automated process it cannot generate a "new" 
> work - at least, not under the laws of the US - so the signature itself 
> cannot have a copyright at all.
>
> DRH
> PS: This is the exact same reason that the GPL cannot apply to a Bison 
> generated parser in the US. The "input" file that causes Bison to generate 
> the output can have a copyright, but not the output - no matter what RMS or 
> anyone else wants, and no matter what the GPL says about it.

I do not suggest that copyright subsists in the signature or in the
signing key.  Whether it does is irrelevant to the signing key being
part of the source code (when the signature is needed for the binary
to work properly).

Similarly, copyright might not subsist in a simple linker script --
its content being determined by the operating system and perhaps the
rest of the program's source code -- but under the GPL, the linker
script would be part of the source code for a compiled version.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-14 Thread Michael Poole
[EMAIL PROTECTED] writes:

> On Fri, 15 Jun 2007, Alexandre Oliva wrote:
>
>> Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
>>
>> On Jun 14, 2007, Bill Nottingham <[EMAIL PROTECTED]> wrote:
>>
>>> OK. Let's take this to the simple and logical conclusion. A signed
>>> filesystem image containing both GPL and non-GPL code. From your
>>> point A, this is a derived work.
>>
>> I claim the signature is derived from the GPLed bits, yes.  Whether
>> that's a derived work, in the legal sense, I'm not qualified to say.
>
> it's also derived from the non-GPLed bits as well.
>
> so if it were a derived work in a legal sense (nessasary for your
> argument to have any legal meaning) then it's now illegal to make and
> distribute a checksum of a CD that contains software with incompatible
> licenses.

It is not necessary for the end item to be a derived work in order for
the GPL to apply.  A literal copy is not a derived work; a translation
is not a derived work; an executable version of a program is not a
derived work of its source code; and so forth.

What is necessary is that the "work based on the [GPLed] Program" be
more than a mere aggregation of the GPLed component(s) with non-GPLed
components.  The fact that part of the work-as-a-whole is a descriptor
of the GPLed part does not mean all descriptions the GPLed part are
governed by the GPL.  The critical factor is that the GPLed part will
not function properly without the DRM signature.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-14 Thread Michael Poole
Linus Torvalds writes:

> On Thu, 14 Jun 2007, Michael Poole wrote:
>>
>> If the DRM signature and program executable are coupled such that they
>> are not useful when separated, the implication to me is that they form
>> one work that is based on the original Program.  This is beyond the
>> GPL's permission for "mere aggregation".
>
> So you want to make things like a 160-bit SHA1 hash of a binary be a 
> "derived work" of that software?

No.  That is why I specified "not useful when separated".  I also
intentionally avoided the phrase "derived work": the legal definition
of derived work is based on entirely different factors.

If the signature is one that serves to indicate origin, to detect
tampering, or the other things you mentioned, the program's binary is
useful when separated from the signature.  My objection arises when a
functionally equivalent binary -- including advertised functions such
as "runs on platform XYZ" -- cannot be produced from the distributed
source code.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-14 Thread Michael Poole
Daniel Hazelton writes:

> On Thursday 14 June 2007 22:13:13 Michael Poole wrote:
>
>> The fundamental reason for this is that neither the executable code
>> nor the digital signature serves the desired function alone.  The user
>> received a copy of the executable for a particular purpose: to run the
>> program on a particular platform.  With DRM signatures, only the
>> combination of program and signature will perform that function, and
>> separating the two based on strictly read legal definitions is risky.
>
> I agree.
>
>> The question of whether DRM signatures are covered by the license must
>> be resolved before one can determine whether Tivo gave "*EXACTLY*" the
>> same rights to object-code recipients as Tivo received.  GPLv2 is
>> worded such that the answer to this does not depend on whether one is
>> in file A and the other in file B, or whether one is on hard drive C
>> and the other is in flash device D, as long as they are delivered as
>> part of one unit; it *might* matter if, say, one is received on
>> physical media and the other is downloaded on demand.
>
> I have read the GPLv2 at least three times since it was pointed out that I 
> had 
> forgotten part of it. At no point can I find a point where Tivo broke the 
> GPLv2 requirement that they give the recipients of the object code the same 
> rights they received when they acquired a copy of the object or source code.

I am trying to reconcile your responses to those two paragraphs.

If the DRM signature and program executable are coupled such that they
are not useful when separated, the implication to me is that they form
one work that is based on the original Program.  This is beyond the
GPL's permission for "mere aggregation".

If they are one work, and the original Program was licensed under the
GPLv2, the combined work must also be licensed under the terms of the
GPLv2.

The input files required to generate a DRM-valid digital signature are
part the preferred form for modifying that work.

If those bits are not distributed along with the rest of the GPL'ed
work, the distributor is either not giving the same rights to the end
user, not distributing the source code for the work, or both.  Which
is it?

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-14 Thread Michael Poole
Daniel Hazelton writes:

> What rights did they give to "downstream" recipients of the "object code" 
> version? *EXACTLY* those they received from the GPLv2.

Doing the e-mail equivalent of yelling about this will not change the
fact that people who think Tivo did something wrong -- legally and/or
morally -- consider DRM locks on a piece of software to be part of the
"work based on the Program" that is governed by the GPL.

The fundamental reason for this is that neither the executable code
nor the digital signature serves the desired function alone.  The user
received a copy of the executable for a particular purpose: to run the
program on a particular platform.  With DRM signatures, only the
combination of program and signature will perform that function, and
separating the two based on strictly read legal definitions is risky.

The question of whether DRM signatures are covered by the license must
be resolved before one can determine whether Tivo gave "*EXACTLY*" the
same rights to object-code recipients as Tivo received.  GPLv2 is
worded such that the answer to this does not depend on whether one is
in file A and the other in file B, or whether one is on hard drive C
and the other is in flash device D, as long as they are delivered as
part of one unit; it *might* matter if, say, one is received on
physical media and the other is downloaded on demand.

(Linus likes to say that FSF counsel thinks that Tivo did not violate
GPLv2.  I suspect the actual situation is that FSF counsel believes
that there is no case law on point, and that it could go either way,
making it improper to publicly claim that Tivo violated any copyright.
Until a court rules on a close-enough case, the question of whether
GPLv2 covers DRM signatures remains open.  In the mean time, it makes
more sense for the FSF to issue a new license that squarely addresses
this -- such as the GPLv3 -- and persuade as many developers as
possible that using it is the best way to protect free software.)

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-14 Thread Michael Poole
Matt Keenan writes:

> Michael Poole wrote:
>> Matt Keenan writes:
>>
>>   
>>> Alexandre Oliva wrote:
>>> 
>>>> Err, no.  Software, per legal definitions in Brazil, US and elsewhere,
>>>> require some physical support.  That's the hard disk in the TiVO DVR,
>>>> in this case.  I don't see how this matters, though.
>>>>
>>>>   
>>>>   
>>> I'm now intrigued, where are these (Brazilian and US) definitions
>>> stipulated, and under what authority?
>>> 
>>
>> In the US, 17 USC 101 (the "Definitions" section of the title dealing
>> with Copyright) makes this definition:
>>
>> A "computer program" is a set of statements or instructions to be
>> used directly or indirectly in a computer in order to bring about
>> a certain result.
>>
>> As its purpose is to outline the scope of copyright law, this
>> definition is made under the authority granted to Congress by Article
>> I, Section 8 of the United States Constitution.
>>
>>   
> But where is the part that says it "requires some physical support"? It
> says what it is; "a set of statements or instructions", how it should be
> used; "to be used directly or indirectly in a computer", and what
> purpose it serves; "in order to bring about a certain result", but it
> doesn't seem to indicate that it "requires physical support" aka needing
> some physical representation. I suspect this argument boils down to the
> philosophical debate of whether ideas (in this case software) can be
> truely devoid of the physical.

Sets of statements or instructions that cannot "be used directly or
indirectly in a computer in order to bring about a certain result"
are, for the purposes of copyright law, not software.  "A computer" is
a physical device.  It always has been a physical device, except when
"computer" referred to a person who performed computations -- and that
meaning fell out of common use 40 years ago.  Any suggestion that the
requirement to be usable on a physical device is significantly
different from "require[s] some physical support" is laughably stupid.

17 USC 102 requires that copyright protection only subsists in works
that are "fixed in any tangible medium of expression" -- which
obviously includes paper and hard drives, and has been ruled to
include volatile program memory (the 9th Circuit's holding to this
effect in MAI Systems Corp. v. Peak Computer, Inc. is what inspired
the addition of 17 USC 117(c)).  If the set of instructions exist only
in transmission or in someone's head, they are not protected by
copyright law.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-14 Thread Michael Poole
Ingo Molnar writes:

> this is largely irrelevant to my argument: the FSF is clearly trying to 
> extend the scope of the GPL to restrict the distribution of certain 
> hardware+software combinations. The FSF is not really arguing that the 
> boundary between software and hardware is diffuse. (which btw. it 
> clearly is) The FSF simply wants to be able to say via the GPLv3: "to be 
> able to distribute GPL-ed software, the hardware is required to do this 
> and this".

Most people arguing for the expansive interpretation do not really
care what hardware is combined with what software.  They care about
the ability for the user (in the GPLv2's terms, someone who receives
GPL'ed software) to have comparable ability to modify and
(re-)distribute the software as the software distributor does.  The
issue of GPLed software on DRMed hardware applies equally to digital
video recorders, where the hardware and software distributor are
usually the same, and video game consoles, where they are not.

There is no good reason to treat a "GPL-incompatible" hardware
platform (for example, incompatible due to restrictions on the keys to
generate digital signatures) differently than a "GPL-incompatible"
patent area.  If a software distributor cannot simultaneously comply
with the GPL and his other obligations, he should either not
distribute the software or be prepared to face the liability from
breaching his obligations.

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


Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

2007-06-14 Thread Michael Poole
Matt Keenan writes:

> Alexandre Oliva wrote:
>>
>> Err, no.  Software, per legal definitions in Brazil, US and elsewhere,
>> require some physical support.  That's the hard disk in the TiVO DVR,
>> in this case.  I don't see how this matters, though.
>>
>>   
> I'm now intrigued, where are these (Brazilian and US) definitions
> stipulated, and under what authority?

In the US, 17 USC 101 (the "Definitions" section of the title dealing
with Copyright) makes this definition:

A "computer program" is a set of statements or instructions to be
used directly or indirectly in a computer in order to bring about
a certain result.

As its purpose is to outline the scope of copyright law, this
definition is made under the authority granted to Congress by Article
I, Section 8 of the United States Constitution.

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


Re: GPL violation by CorAccess?

2005-04-20 Thread Michael Poole
Steven Rostedt writes:

> On Wed, 2005-04-20 at 14:57 +0200, Arjan van de Ven wrote:
>> On Wed, 2005-04-20 at 08:49 -0400, Steven Rostedt wrote:
>> > On Wed, 2005-04-20 at 09:30 +0200, Bernd Petrovitsch wrote:
>> > 
>> > > 
>> > > As long as they do not statically link against LGPL (or GPL) code and as
>> > > long as they do not link dynamically agaist GPL code. And there are
>> > > probably more rules .
>> > > 
>> > 
>> > Actually, I believe that the LGPL allows for static linking as well.
>> 
>> it does, as long as you provide the .o files of your own stuff so that
>> the end user can relink with  say a bugfixed version of library.
>
> I don't see that in the license.  As point 5 showed: "Such a
> work, in isolation, is not a derivative work of the Library, and
> therefore falls outside the scope of this License."

"Such a work" refers to "A program that contains no derivative of any
portion of the library."  A program that is statically linked against
the library clearly contains part or all of the library, and cannot
qualify for the lower threshold of section 5.  Section 5 is talking
about late binding to the library; dynamic linking is one example.

For programs distributed as object code that does contain part of the
library, the distributor must -- sooner or later -- comply with 6(a)
(allow the user to relink) or 6(b) (use dynamic linking).

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


Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

2005-04-11 Thread Michael Poole
David Schwartz writes:

>>Copyright law only _explicitly_ grants a monopoly on preparation of
>>derivative works.  However, it is trivial, and overwhelmingly common,
>>for a copyright owner to grant a license to create a derivative work
>>that is conditional on how the licensee agrees to distribute (or not
>>distribute) the derivative work.
>
>   This would, of course, only make sense if you *had* to agree to the 
> license
> to *create* the derivative work. If you were able to create the derivative
> work under first sale or fair use rights, then the restrictions in the
> contract would not apply to you.

This would, of course, only make sense if fair use or first sale
rights *allow* the creation of derivative works.  I have seen nothing
in this thread or in the statutes to suggest that they do.

Do not forget that your copyright interest in a derivative work is
limited to the creative elements which you contributed.  Simply having
a license (or right) to create a derivative work does not permit you
to infringe the original work's copyright, which still subsists in the
derivative work insofar as the derivative work contains copyrightable
elements from the original work.

Even if some court agrees with your hypothesis that the compiled
program is a derivative work of the source (which I doubt would
happen), and you find some permission outside of the GPL to prepare
that derivative work, you still need permission to copy it further.

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


Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

2005-04-11 Thread Michael Poole
Humberto Massa writes:

> David Schwartz wrote:
>
>> > On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
>>
>>
>> >> The way you stop someone from distributing part of your work is
>> >> by arguing that the work they are distributing is a derivative
>> >> work of your work and they had no right to *make* it in the first
>> >>  place. See, for example, Mulcahy v. Cheetah Learning.
>>
>>
>> > Er, that's one way, but not *the* way.  I could grant you
>> > permission to create derivatives of my work, but not to
>> > redistribute them.  To stop you from distributing them, I'd argue
>> > that you had no right to distribute them--you *did* have the right
>> > to make it in the first place.
>>
>>
>>  You could do that be means of a contract, but I don't think you could
>>  it do by means of a copyright license. The problem is that there is
>>  no right to control the distribution of derivative works for you to
>>  withhold from me.
> Wrong, sorry. Copyright is a *monopoly* on some activities (copy,
> distribution of copies, making *and* distribution of derivative works).

Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works.  However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to distribute (or not
distribute) the derivative work.

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


Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

2005-04-04 Thread Michael Poole
Sven Luther writes:

> Hello,
>
> 
> Current linux kernel source hold undistributable non-free firmware blobs, and
> to consider them as mere agregation, a clear licence statement from the
> copyright holders of said non-free firmware blobls is needed, read below for
> details.
> 
>
> Please keep everyone in the CC, as not everyone reads debian-legal or LKML.

This question comes up every four or five months.  You might have even
been the last one to raise this question on one or more of the mailing
lists you cc'ed.  Please, go check the list archives for the previous
(lengthy and multiple) discussions about this topic.

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


Re: eepro100/usb interrupts stop with 2.4.x kernels?

2001-05-10 Thread Michael Poole

Alan Cox <[EMAIL PROTECTED]> writes:

> > What seems to happen is that the kernel stops seeing interrupts on the
> > IRQ shared by eth0 (my outside interface) and usb-uhci.  I can still
> > ssh in on eth1, and when I do, syslog contains things like "eth0:
> > Interrupt timed out" and usb-uhci griping about devices that failed to
> > accept new endpoints.
> 
> Do you see this if you run a -ac kernel or apply the APIC 440BX patch ?

I haven't tried either, but I'm about to reboot into 2.4.4-ac4 to see
if it helps.  If it still happens, I'll get more of the syslog output
and try to figure out what got wedged.

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



eepro100/usb interrupts stop with 2.4.x kernels?

2001-05-10 Thread Michael Poole

Since about 2.4.2, I have been seeing intermittent hangs on my system;
usually once or twice a week, but once just 10 minutes after rebooting.

What seems to happen is that the kernel stops seeing interrupts on the
IRQ shared by eth0 (my outside interface) and usb-uhci.  I can still
ssh in on eth1, and when I do, syslog contains things like "eth0:
Interrupt timed out" and usb-uhci griping about devices that failed to
accept new endpoints.

I'm not sure if for some reason my chipset stopped passing these
interrupts on to the kernel, or if the kernel got into some funny
state and stopped accepting those interrupts.  Any hints on where I
should look?

>From /proc/interrupts now:
   CPU0   CPU1   
  0: 243741 233914IO-APIC-edge  timer
  1:  4  0IO-APIC-edge  keyboard
  2:  0  0  XT-PIC  cascade
  8:  0  0IO-APIC-edge  rtc
 10:  0  0   IO-APIC-level  EMU10K1
 11:  18775  17937   IO-APIC-level  usb-uhci, eth0
 12:   1221   1236   IO-APIC-level  eth1
 14:  84039  68162IO-APIC-edge  ide0
 15: 18 18   IO-APIC-level  BusLogic BT-950
NMI:  0  0 
LOC: 477548 477547 
ERR:  0

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



Re: NT soon to surpass Linux in specweb99 performance?

2001-02-02 Thread Michael Poole

Paul Flinders <[EMAIL PROTECTED]> writes:

> Gregory Maxwell wrote:
> 
> > Looks like TUX caught MS's attention:
> > http://www.spec.org/osg/web99/results/res2000q4/web99-20001211-00082.html
> >
> > Anyone know if their method of achieveing this is as flexible as TUX, or is
> > their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the
> > specweb dyanmic stuff in x86 assembly in their microkernel? :)
> 
> Yeah, but Tux 2 is still faster on the same/similar hardware
> 
> http://www.spec.org/osg/web99/results/res2000q4/web99-20001127-00075.html

Well, if you look closely, the Tux 2 system had an extra GigE card and
5 9GB 10KRPM drives instead of 1 9GB 10KRPM drive plus 8 16GB 15KRPM
drives under IIS, so the hardware wasn't exactly the same for both.

Perhaps more telling is that in both cases the "Conforming
Simultaneous Connections" was the same as the "Requested Connections"
-- suggesting that neither TUX 2.0 nor IIS were pushed to the breaking
point in the tests.

Before gloating about holding the highest performance, compare with
Zeus running on a (much beefier) IBM eServer:
http://www.spec.org/osg/web99/results/res2001q1/web99-20001225-00092.html

(And of course the normal disclaimers apply about how little benchmark
results reflect what "average" commercial deployments see.)

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



Re: No Bug: accept discards socket options/O_NONBLOCK

2000-09-15 Thread Michael Poole

Matthias Andree <[EMAIL PROTECTED]> writes:

> On Fri, 15 Sep 2000, David S. Miller wrote:
> 
> > Every Linux inetd in the world would instantly stop working.
> 
> Why should it? inetd.c does not touch fd flags. No F_SETFL, no
> O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2)
> semantics?

Most of the programs called by inetd don't expect non-blocking I/O on
their stdin and stdout, which they would suddenly get if accept()'ed
sockets inherited the non-blocking nature of inetd's listening socket.

Personally, I think that the common case is that the caller will want
the same blocking attribute for an accept()'ed socket as on the
listening socket it came from, and inetd is the only app I have seen
offered as a counterexample.  If it's just one app, it can easily be
changed and marked as required for upgrades to kernels that have the
same semantics as the BSDs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/