Do I have to release the patch for a GPL software under GPL?
Dancefire
I am confusing on GPL now, I need someone to clear me.
Do I have to release the patch under GPL if the patch is for a GPL software?
As my understanding, for example, If I modified Linux kernel, I do not have
to release it under GPL if I use it privately, unless I make it public. But
how about the patch for the kernel? That is, if I generate the patch of my
modification for the Linux Kernel, and never release the modified Linux
kernel to public, however, I want to sell the kernel patch of the Linux to
customers as whatever license as I want, but I don’t want the patch under
GPL for some reason. Can I?
Dancefire
Â
--
CCNA
I am expecting to do research on Operating System, Embedded System and
Network Security.
Bernd Jendrissek
Hash: SHA1
In article <mailman.1491.114685415...@gnu.org>
Dancefire <danc...@gmail.com> wrote:
>I am confusing on GPL now, I need someone to clear me.
Or maybe you're not confused, but just unhappy that it doesn't condone
your desire to take away some of your customers' freedoms.
>Do I have to release the patch under GPL if the patch is for a GPL
>software? As my understanding, for example, If I modified Linux
>kernel, I do not have to release it under GPL if I use it privately,
>unless I make it public. But how about the patch for the kernel? That
>is, if I generate the patch of my modification for the Linux Kernel,
>and never release the modified Linux kernel to public, however, I want
>to sell the kernel patch of the Linux to customers as whatever license
>as I want, but I don?t want the patch under GPL for some reason. Can I?
Your customers will have to apply the patch themselves. If you give
them an already patched kernel, you will have to release it to them with
the GPL (modulo BSD-type parts of the kernel) covering the *whole*
derived work, otherwise your redistribution will be in violation of the
only licence you have to redistribute, the GPL (module BSDish and public
domain parts).
IANAL BTW.
- --
"If you lie to the compiler, it will get its revenge." - Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/
iD8DBQFEW8F/wyMv24BBd/gRAhRrAKCTpbSQ26Ep8nQ9+Vf42yGkFS76jACfQc9x
DE538E2WZMAE7w/gj9Dv5Tw=
=+ie8
-----END PGP SIGNATURE-----
Merijn de Weerd
> In article <mailman.1491.114685415...@gnu.org>
> Dancefire <danc...@gmail.com> wrote:
>>and never release the modified Linux kernel to public, however, I want
>>to sell the kernel patch of the Linux to customers as whatever license
>>as I want, but I don?t want the patch under GPL for some reason. Can I?
>
> Your customers will have to apply the patch themselves. If you give
> them an already patched kernel, you will have to release it to them with
> the GPL (modulo BSD-type parts of the kernel) covering the *whole*
> derived work, otherwise your redistribution will be in violation of the
> only licence you have to redistribute, the GPL (module BSDish and public
> domain parts).
In additions, your customers will not be able to distribute
the patched kernel themselves either. So even if you give them
just the patch, it won't be of much use to them. Well unless
they use the kernel for an internal computer.
Merijn
--
Remove +nospam to reply
Alfred M. Szmidt
software?
Ask yourself the following, is the patch a deriviate work? If it is,
then it must be licensed under the terms of the GNU GPL.
As my understanding, for example, If I modified Linux kernel, I do
not have to release it under GPL if I use it privately, unless I
make it public.
You are confusing releasing and licensing.
But how about the patch for the kernel? That is, if I generate the
patch of my modification for the Linux Kernel, and never release
the modified Linux kernel to public, however, I want to sell the
kernel patch of the Linux to customers as whatever license as I
want, but I don't want the patch under GPL for some reason. Can I?
You can charge a fee for distributing the patch (or for any free
software infact) or even a tarball of the whole Linux tree with the
patch included. What you must do though is give the people you
distribute the patch to (for a fee or not) the same rights as you
recived; i.e. you must follow the terms of the GNU GPL since the patch
is derived from a work which is licensed under the GNU GPL. So in
short, no.
I suggest that you read the GNU GPL FAQ[0], it contains many answers
to these types of questions. And I'd also like to recommend the
essays at http://www.gnu.org/philosophy/, most notably `Why Software
Should Be Free' by RMS.
Cheers.
[0]: http://www.gnu.org/licenses/gpl-faq.html
Byron A Jeff
Dancefire <danc...@gmail.com> wrote:
>Hi, all,
Hi.
>I am confusing on GPL now, I need someone to clear me.
I'll take a stab at it.
>Do I have to release the patch under GPL if the patch is for a GPL
>software?
Yes.
>As my understanding, for example, If I modified Linux kernel, I do not
>have
>to release it under GPL if I use it privately, unless I make it public.
That's correct.
>But how about the patch for the kernel?
The same because the patchis for GPL software.
> That is, if I generate the patch of =
>my
>modification for the Linux Kernel, and never release the modified Linux
>kernel to public, however, I want to sell the kernel patch of the Linux =
>to
>customers as whatever license as I want, but I don=92t want the patch =
>under
>GPL for some reason. Can I?
Nope. Since the patch is for GPL software, it falls under the GPL.
There have been a ton of discussions about library/plugin interfaces that
have the same issues. Since the only way this patch can be used is to bind
it with GPL source, it must be GPLed.
Of course I have to beg the question: why bother to use GPL software when your
intent is to break the sprit of the license? GPL software is licensed the
way it is so that everyone can benefit from and contribute to the code base.
Proprietizing a patch is the anthesis of what the GPL and free software is
all about.
The original code is put under the GPL precisely to prevent you from doing
what you propose to do. Why would you even want to use GPL software if it
runs so counter to your values?
The answer is simple: Write all of your own software. Then you can license it
any way that you wish. See how simple that is?
BAJ
Dancefire
Thanks for reply. I am not going to break the freedom. I just want to clear
the border of free.
For example, if there is a military organization want to use Linux as a
kernel of their operating system, but, of course, they have to patch the
kernel for extra secure. However, for security reason, they can't make the
patch public. So what should they do? Forget Linux and use *BSD instead? Or
they can use the patched Linux kernel without public it.
This maybe is simple, since the kernel is not given to anyone, only internal
using. It's get more complex if they give the kernel/patch to another
military/security agent organization. Do they have to make the patch open?
If they have to, of course, they can't choose Linux.
I am trying to make its possible to use Linux under this situation,
otherwise, *BSD is the only choice.
Cheers.
Dancefire
>Hi, all,
Hi.
Yes.
That's correct.
BAJ
_______________________________________________
gnu-misc-discuss mailing list
gnu-misc...@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
David Kastrup
> Thanks for reply. I am not going to break the freedom. I just want
> to clear the border of free.
>
> For example, if there is a military organization want to use Linux
> as a kernel of their operating system, but, of course, they have to
> patch the kernel for extra secure. However, for security reason,
> they can't make the patch public. So what should they do? Forget
> Linux and use *BSD instead? Or they can use the patched Linux kernel
> without public it.
Sure. No need publishing.
> This maybe is simple, since the kernel is not given to anyone, only
> internal using. It's get more complex if they give the kernel/patch
> to another military/security agent organization. Do they have to
> make the patch open?
As long as the other organization is acting on their behalf, as their
agent, not becoming owner of any physical media containing the
software, this should not be a problem.
> I am trying to make its possible to use Linux under this situation,
Oh, there is nothing you can do in that respect.
> otherwise, *BSD is the only choice.
If you call that a choice. You might want to read the GPL FAQ.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
John Hasler
> This maybe is simple, since the kernel is not given to anyone, only
> internal using. It's get more complex if they give the kernel/patch to
> another military/security agent organization. Do they have to make the
> patch open?
No. They merely need to provide source to those they distribute binaries
to. The GPL does not require publication.
> I am trying to make its possible to use Linux under this situation,
> otherwise, *BSD is the only choice.
It's quite possible and legal. Just be sure you always provide source
(under the terms of the GPL, of course) along with binaries to anyone you
distribute to. You get to choose who to distribute binaries to, and as
long as you provide source with them you need not provide source to anyone
else.
BTW if the source for the patch is of any use to the opposition in breaking
the security it supposedly provides it isn't worth much anyway. Better to
contribute your improvements to the main kernel and let the community help
you debug and improve them.
You _do_ know about SELinux, don't you?
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Byron A Jeff
>Thanks for reply. I am not going to break the freedom. I just want to clear
>the border of free.
What you propose is well on the other side of the border.
>For example, if there is a military organization want to use Linux as a
>kernel of their operating system, but, of course, they have to patch the
>kernel for extra secure. However, for security reason, they can't make the
>patch public. So what should they do?
That's like comparing apples and gorillas. This is a completely different
problem from the original.
In the above case it's simple: Keep the patch internal to the organization.
The GPL's rights are all about distribution. The scenario you describe above
requires not distributing the patch. The GPL is fine with that. It specifically
states that internal distribution within an organization is not a public
distribution.
However, your original post was questioning the ability to relicense a
distributed patch for GPL software. That's a horse of a completely different
color. In that case you are precisely talking about distribution, and so the
full weight of the GPL is in effect.
> Forget Linux and use *BSD instead?
Nope.
> Or they can use the patched Linux kernel without public it.
Yes. But again that wasn't the issue you originally presented.
>This maybe is simple, since the kernel is not given to anyone, only internal
>using.
That's right.
> It's get more complex if they give the kernel/patch to another
>military/security agent organization. Do they have to make the patch open?
They must give the source to the other military organization that they
distribute the patch to. Also the code must be GPLed. Often when talking
about the GPL there is some confusion about what "public distribution" means.
It means that you must distribute the source to whomwever you distribute the
work. It also means that you cannot restrict others from redistributing if
they so choose. If Military A has a patch and gives it to Military B, the
only obligation is that the source goes to Military B. Now if Military B
decided to then keep it in house, that's their business. However, there is
nothing that Miliary A can do to keep Military B from redistributing to
Military C, or the general public if they so desire.
>If they have to, of course, they can't choose Linux.
OK. That's not a problem. You can't have something be free except when it's
not. It doesn't work.
>I am trying to make its possible to use Linux under this situation,
>otherwise, *BSD is the only choice.
So choose BSD. There's no problem there.
BTW the NSA has patched up and used a modified, secured Linux kernel.
You can read about it here:
http://www.nsa.gov/selinux/info/faq.cfm
BAJ
Merijn de Weerd
> BTW the NSA has patched up and used a modified, secured Linux kernel.
> You can read about it here:
>
> http://www.nsa.gov/selinux/info/faq.cfm
Has anyone ever done a comparative study on OpenBSD versus SELinux?
Alexander Terekhov
Byron A Jeff wrote:
[...]
> However, your original post was questioning the ability to relicense a
> distributed patch for GPL software. That's a horse of a completely different
> color. In that case you are precisely talking about distribution, and so the
> full weight of the GPL is in effect.
Distribution under 17 USC 109 aside for a moment, the GPL has no weight
whatsoever for a patch that isn't an copy or a derivative work of some
GPL'd original. And it must be infringing (in absence of a license). It
means that a patch must contain some protected (under copyright law)
expression (i.e. elements not filtered out by the AFC test) from the
GPL'd original. Note that mere references to original code don't count
as protected elements. It is not that hard to create a patch where no
protected expression is taken from the original at all, or at least
separate a patch into GPL'd and GPL-free components.
regards,
alexander.
Dancefire
I am sorry, I am not quite understand your words.
As you said, under "17 USC 109", the patch of the GPL software is not a copy
or a derivative work of the GPL software, so, I can distribute the patch
under whatever license I want, right? The patch should not be limited by the
software license which I patched for, right?
Cheers.
Dancefire
-----Original Message-----
From: gnu-misc-discuss-bounces+dancefire=gmai...@gnu.org
[mailto:gnu-misc-discuss-bounces+dancefire=gmai...@gnu.org] On Behalf Of
Alexander Terekhov
Sent: Thursday, May 11, 2006 2:49 AM
To: gnu-misc...@gnu.org
Subject: Re: Do I have to release the patch for a GPL software under GPL?
regards,
alexander.
Alexander Terekhov
Dancefire wrote:
>
> Hi, Alexander,
>
> I am sorry, I am not quite understand your words.
>
Consolidated know-how on escaping the GPL under 17 USC 109 can be
found in "Distributing GPL software" thread on debian-legal.
http://lists.debian.org/debian-legal/2006/01/msg00163.html
http://lists.debian.org/debian-legal/2006/01/msg00166.html
http://lists.debian.org/debian-legal/2006/01/msg00174.html
and etc. (read the entire thread).
regards,
alexander.
Alfred M. Szmidt
not a copy or a derivative work of the GPL software, so, I can
distribute the patch under whatever license I want, right? The
patch should not be limited by the software license which I patched
for, right?
Ask yourself the following, and all your questions will be answered:
Does the patch work without the GPLed software? If it doesn't, then
it is clearly a deriviate work. The opposite isn't true in all cases,
and requires a more detailed explanation about the patch and how it
interacts with the GPLed program.
Alexander Terekhov
"Alfred M. Szmidt" wrote:
[...]
> Ask yourself the following, and all your questions will be answered:
> Does the patch work without the GPLed software? If it doesn't, then
> it is clearly a deriviate work.
It may well be a "deriviate" work (whatever that means in the GNU
Republic). But this "test" has absolutely nothing to do with the
legal meaning of "derivative" regarding computer program works --
stuff protected under Berne Convention as literary works (and,
under US case law, modulo the AFC test).
regards,
alexander.
John Hasler
> I am sorry, I am not quite understand your words.
No one understands Terekhov's words. That's because they make no sense.
Ignore him. He's a troll, and an inept one at that.
Gordon Burditt
> not a copy or a derivative work of the GPL software, so, I can
> distribute the patch under whatever license I want, right? The
I believe the original author meant *if* the patch of the GPL
software is not a copy or derivative work of the GPL software, you
can distribute the patch under whatever license you want.
A context diff is arguably a derivative work of the original
since it includes lines from the original. A sufficiently complex
modification would put the entire original in the context diff.
Including the entire original would clearly make it a derivative work.
The output of "diff -e", though, doesn't include the original lines.
If all the patch does is include NEW code or delete old code, there's
no code in there from the original in there at all. On the other
hand, something like changing:
cp = malloc(strlen(foo+1));
TO:
cp = malloc(strlen(foo)+1);
still leaves some of the original line in the new line (the new line is the
only one included in a diff -e patch). You can argue about how much of
that you can do before the line is crossed. I am not a lawyer.
> patch should not be limited by the software license which I patched
> for, right?
*IF* the patch is not a derivative work of the original, right.
This is far from a given.
>Ask yourself the following, and all your questions will be answered:
>Does the patch work without the GPLed software?
I don't think this is the appropriate test. There are a number of
user-level programs which will only run on Linux (say, because they
need the video4linux drivers, NOT included in the distribution).
They are NOT derivatives of Linux because of that. Few programs
include a <stdio.h> because they expect the compiler (which might
be gcc) to supply that. This does NOT make them derivatives of gcc
because of that.
>If it doesn't, then
>it is clearly a deriviate work.
I don't buy that. This makes virtually all software a derivative
of a *POWER CORD*. It makes virtually all modern technology a
derivative of *OIL*.
>The opposite isn't true in all cases,
>and requires a more detailed explanation about the patch and how it
>interacts with the GPLed program.
Gordon L. Burditt
Alfred M. Szmidt
It has alot to do with the legal meaning of derivative. What doesn't
have anything to do with the legal meaning of derivative is your
constant blabbering. It also has to do with the acutal GPL.
| 2. You may modify your copy or copies of the Program or any
| portion of it, thus forming a work based on the Program, and copy
| and distribute such modifications or work under the terms of Section
| 1 above, provided that you also meet all of these conditions:
|
| a) You must cause the modified files to carry prominent notices
| stating that you changed the files and the date of any change.
|
| b) You must cause any work that you distribute or publish, that in
| whole or in part contains or is derived from the Program or any
| part thereof, to be licensed as a whole at no charge to all third
| parties under the terms of this License.
|
| c) If the modified program normally reads commands interactively
| when run, you must cause it, when started running for such
| interactive use in the most ordinary way, to print or display an
| announcement including an appropriate copyright notice and a
| notice that there is no warranty (or else, saying that you provide
| a warranty) and that users may redistribute the program under
| these conditions, and telling the user how to view a copy of this
| License. (Exception: if the Program itself is interactive but
| does not normally print such an announcement, your work based on
| the Program is not required to print an announcement.)
Alexander Terekhov
Gordon Burditt wrote:
[...]
> Including the entire original would clearly make it a derivative work.
A *modified* original is clearly a derivative work. But the scope
of that derivative work doesn't encompass independent code merely
aggregated with that derivative work. It's a compilation of a
derivative work (modified original) and other independent (in the
copyright sense) computer program works.
regards,
alexander.
David Kastrup
> Hi, Alexander,
>
> I am sorry, I am not quite understand your words.
Google for other posts by Alexander. He is a well-known troll in this
group trying to spread confusion and doubt about the GPL.
Just ignore any advice of his, it's bullshit, and intentionally
misleading. Some hobby of his.
Dancefire
Well, we just put the discussion of whether the patch should be under GPL
away. We just assume it is under GPL.
So, now, at my current understanding, I can distribute the patch to another
one, with/without commercial behavior. And I have the rights that I do not
public the source code, the only thing I have to do is when I try to
distribute the patched kernel I have to make the whole source code available
to the receiver, and the patch is still under GPL. Right?
And after I distribute the patched kernel, can the receiver public the
patch? If yes, can I put a limit to public the patch? It's ok when we
distribute the patched kernel with source code also available to which we
want to distribute the patched kernel. However, make the patch public
available is not our intention.
We can and did contribute much code to open source community, but "much"
doesn't mean "all", and should not *have to* be all. In the real world,
obviously, not everyone wants to make all the stuff to public. So, there are
some code in the real world will face the situation I described above.
Dancefire
-----Original Message-----
From: gnu-misc-discuss-bounces+dancefire=gmai...@gnu.org
[mailto:gnu-misc-discuss-bounces+dancefire=gmai...@gnu.org] On Behalf Of
David Kastrup
Sent: Saturday, May 13, 2006 12:38 AM
To: gnu-misc...@gnu.org
Subject: Re: Do I have to release the patch for a GPL software under GPL?
"Dancefire" <danc...@gmail.com> writes:
Gordon Burditt
A context diff between two files where enough changes had been made
to include the entire original is, to me, not "mere aggregation".
The original certainly isn't usable in the form that it is. (Neither
is the modified original obtained from using the patch on the
unmodified original). It's not like taking the original and the
modified version and sticking them together in a tar or cpio archive.
A patch is something that lets you take the original file (normally
not distributed as part of the patch) and create from it a modified
original. If it doesn't make changes to the original, there's no point
in having a patch.
Gordon L. Burditt
David Kastrup
> Well, we just put the discussion of whether the patch should be
> under GPL away. We just assume it is under GPL.
>
> So, now, at my current understanding, I can distribute the patch to
> another one, with/without commercial behavior. And I have the rights
> that I do not public the source code, the only thing I have to do is
> when I try to distribute the patched kernel I have to make the whole
> source code available to the receiver, and the patch is still under
> GPL. Right?
>
> And after I distribute the patched kernel, can the receiver public the
> patch?
Yes.
> If yes, can I put a limit to public the patch?
No.
> It's ok when we distribute the patched kernel with source code also
> available to which we want to distribute the patched
> kernel. However, make the patch public available is not our
> intention.
You can threaten your customer with whatever consequences you want,
except the law. You can stop business with him, cancel any special
services or whatever. But that's all. Tell the customer that if he
doesn't exercise goodwill according to your needs, you won't either.
But the GPL rules out that you can go after him with the law behind
you.
> We can and did contribute much code to open source community, but
> "much" doesn't mean "all", and should not *have to* be all.
"Should not"? _You_ make use of _all_ of the contribution of some
author under the GPL, so why should you, as the creator of a tiny
patch, be allowed to demand better terms than the author of the main
material?
You want to rip off some person's code for your own sake without
paying him. If you don't like licensing a modification under the GPL,
contact the author and ask him for a different license for which you
are going to pay him reasonable royalties.
> In the real world, obviously, not everyone wants to make all the
> stuff to public. So, there are some code in the real world will
> face the situation I described above.
Yes, that's why the GPL exists. So that people don't consider ripping
off free code and making it proprietary. Exactly to stop people from
that practice, the GPL has been written.
No, there is no way around it, since that is the _purpose_ of the
GPL.
Dancefire
Thanks for reply.
We are obviously not going to rip any opensource software, even the GPL
software we going to patch. What we expect is only make our *tiny* patch
under our control. There is no anyone else code in the tiny patch. We do not
want to restrict the redistribute of the original GPL software, it's not our
business. What we want to do is to put the restriction of redistribution on
the tiny patch we created.
Yes, if without the original GPL software, the patch will not going to work
directly. However, it doesn't mean the patch will make no sense without
original software. We also can port the patch to other software, after port,
the patch can work without the original one.
What I trying to say is there ARE some intelligent properties in the patch
which we want to keep under our control, but we never want to put any
restriction on any one else. So can we protect our own tiny patch not to be
public?
Dancefire
-----Original Message-----
From: David Kastrup [mailto:d...@gnu.org]
Sent: Saturday, May 13, 2006 5:31 AM
To: Dancefire
Cc: gnu-misc...@gnu.org
Subject: Re: Do I have to release the patch for a GPL software under GPL?
David Kastrup
> We are obviously not going to rip any opensource software, even the
> GPL software we going to patch.
You are obviously planning to do just that.
> What we expect is only make our *tiny* patch under our
> control. There is no anyone else code in the tiny patch.
Your "tiny patch" serves no purpose without the GPLed software, so you
effectively add the GPLed software into a proprietary offering against
the explicit wishes and the license you have been granted.
I repeat: if you don't want to heed the conditions of the GPLed
software, contact the original author and offer to pay him for a
license to use his software under different terms and conditions.
> We do not want to restrict the redistribute of the original GPL
> software, it's not our business. What we want to do is to put the
> restriction of redistribution on the tiny patch we created.
You plan to restrict the redistribution of a variant of the original
GPL software. The license does not permit that. Negotiate a
different license. You can't just ignore the license and make up your
own terms.
> Yes, if without the original GPL software, the patch will not going
> to work directly. However, it doesn't mean the patch will make no
> sense without original software. We also can port the patch to other
> software, after port, the patch can work without the original one.
Then do that. You are free to port the patch to whatever software you
like and publish it under terms compatible with the license under
which you received that software.
> What I trying to say is there ARE some intelligent properties in the
> patch which we want to keep under our control, but we never want to
> put any restriction on any one else. So can we protect our own tiny
> patch not to be public?
No.
Alexander Terekhov
Gordon Burditt wrote:
[...]
> A patch is something that lets you take the original file (normally
> not distributed as part of the patch) and create from it a modified
> original. If it doesn't make changes to the original, there's no point
> in having a patch.
Think of a patch containing both modifications and some new independent
computer program works to be added to the same modified file. Something
along the lines of
ORIGINAL:
cp = malloc(strlen(foo+1));
MODIFIED:
cp = my_malloc(my_strlen(foo)+1);
The code for my_malloc() and my_strlen() computer programs is merely
aggregated with modifications to the original. And the scope of the
derivative work (modified original) doesn't encompass independent
code merely aggregated with that derivative work.
regards,
alexander.
Alexander Terekhov
Dancefire wrote:
[...]
> What I trying to say is there ARE some intelligent properties in the patch
> which we want to keep under our control, but we never want to put any
> restriction on any one else. So can we protect our own tiny patch not to be
> public?
As long as those "intelligent properties" in your patch don't contain
any protected expression (google the AFC test) from the GPL'd work you
can license those portions of your patch under any terms you like. The
FSF is on record: <quote> In fact, the GPL itself rejects any automatic
aggregation of software copyrights under the GPL simply because one
program licensed under the GPL is distributed together with another
program that is not licensed under the GPL: "In addition, mere
aggregation of another work not based on the Program with the Program
(or with a work based on the Program) on a volume of a storage or
distribution medium does not bring the other work under the scope of
this License." <quote> http://www.terekhov.de/Wallace_v_FSF_37.pdf
regards,
alexander.
Gordon Burditt
>> GPL software we going to patch.
>
>You are obviously planning to do just that.
>
>> What we expect is only make our *tiny* patch under our
>> control. There is no anyone else code in the tiny patch.
Let us suppose that the patch to GPL-licensed software consists
entirely of the following (excluding the copyright notice on the
patch and the complex user-threatening license for the patch):
_________________________________________________________________________
Obtain version 1.4.3.2.5.7.38.29.9.66.2 of GNU GNU.
Edit file foo.c .
Delete line 287 and re-insert it after line 159.
Delete line 36.
Replace line 34 with the following line:
#define DRM_ENABLE 0
_________________________________________________________________________
This patch could also be presented as an ed(1) script to do the
same thing. Note that there is no code from the original contained
in the patch.
Now, I, Evil Bill Fence Door, copyright this patch, sell it with
onerous copy protection, and for $1,000,000 a copy. The license
that comes with it prohibits re-distribution of the patch. Note
that I'm *not* re-distributing any GPL-licensed software. It's up
to the customer to get it himself.
Sorry, FSF, there's nothing you can do about this. I don't need a
license from you to distribute the patch. It's not derived [hint:
this is a term defined specifically for copyright law] from your
software, so I don't need your license. The fact that the patch
is useless without GPL software is irrelevant - that's not the way
copyright law works. Gas engines are useless without gas, but that
doesn't mean I need a license from an oil company to sell engines.
Now, what about the customer? He gets the patch, he gets a copy of
GPL-licensed GNU GNU, and he applies the patch. According to the
GPL, the customer is allowed to do this if he doesn't distribute
the modified copy. Evil Bill Fence Door doesn't want you to distribute
the patch or the modified copy created with the patch either.
Now, what about the customer distributing the patched version? Is
the patched version a derivative of the original GPL-licensed
software? Almost certainly yes. Is the patched version a derivative
of the patch? Good question, since only one line from the patch
appears in the modified version. I'm not a lawyer. If the answer
is YES, the customer can't distribute the modified version because
of Evil Bill Fence Door's license. If the answer is NO, Evil Bill
Fence Door's license doesn't apply, but how about the GPL? Now,
can the customer distribute the *modified version*, but not Evil
Bill's patch used to create it, and satisfy the GPL? I think the
answer is yes. Evil Bill won't like that. But the customer still
can't distribute Evil Bill's patch.
>Your "tiny patch" serves no purpose without the GPLed software, so you
>effectively add the GPLed software into a proprietary offering against
>the explicit wishes and the license you have been granted.
That isn't true if I don't distribute GPLed software.
>I repeat: if you don't want to heed the conditions of the GPLed
>software, contact the original author and offer to pay him for a
>license to use his software under different terms and conditions.
If I can write the patch in such a way that it does not include code
from what I'm trying to patch, I don't have to do that. For most
patches, I don't think that's practical or possible. For some it
might be.
>> We do not want to restrict the redistribute of the original GPL
>> software, it's not our business. What we want to do is to put the
>> restriction of redistribution on the tiny patch we created.
>
>You plan to restrict the redistribution of a variant of the original
>GPL software. The license does not permit that. Negotiate a
>different license. You can't just ignore the license and make up your
>own terms.
I can ignore the license if what I am distributing is not a (modified
or unmodified) copy of something covered by the license.
Gordon L. Burditt
Alfred M. Szmidt
times', I can copyright it under whatever license I want, but _IF_ I
incoperate it by just adding one call to dtrtaat(); somewhere, then I
Incoperate it into a GNU GPLed work I mean.
must license the function under the terms of the GNU GPL as expressed
above.
Alfred M. Szmidt
> the patch which we want to keep under our control, but we never
> want to put any restriction on any one else. So can we protect
> our own tiny patch not to be public?
As long as those "intelligent properties" in your patch don't
contain any protected expression (google the AFC test) from the
GPL'd work you can license those portions of your patch under any
terms you like.
This is true. But as long as you incoperate those `intelligent
properties'[0] with a GNU GPLed work, in which case you must license
them under the GNU GPL. As such, a patch (a patch by definition is
something that is used to modify an already existing work, and in this
case a GNU GPLed work) is based on another work, and thus forms a
modification to an already GNU GPLed work, and thus the modifications
must be licensed under the GPL GPL (see section 2).
I.e. once again you are simply wrong and blabbering.
[0]: Now, what `intelligent properties' really means can be guessed,
but I will assume anything that can be copyrighted since that is the
only thing that makes sense.
Alfred M. Szmidt
onerous copy protection, and for $1,000,000 a copy. The license
that comes with it prohibits re-distribution of the patch. Note
that I'm *not* re-distributing any GPL-licensed software.
But you _modified_ a GPL licensed work (section 2 of the GNU GPL), and
now are distributing the modifications to this work. It is completely
irrelevant what the form of the patch is, your patch does not work
without the GPLed work, and cannot be used without it so it is a
deriviate work. To create the patch you modified a GPLed work, so it
is clearly a modification in anyway of the word, how you represent
these modifications are once again completely irrelevant. Then there
is the fact that your patch requires the GPLed work to be useful.
Also, the following paragraph might apply:
| These requirements apply to the modified work as a whole. If
| identifiable sections of that work are not derived from the
| Program, and can be reasonably considered independent and separate
| works in themselves, then this License, and its terms, do not
| apply to those sections when you distribute them as separate
| works. But when you distribute the same sections as part of a
| whole which is a work based on the Program, the distribution of
| the whole must be on the terms of this License, whose permissions
| for other licensees extend to the entire whole, and thus to each
| and every part regardless of who wrote it.
I.e. if I wrote a big juciy function to `do the right thing at all
times', I can copyright it under whatever license I want, but _IF_ I
incoperate it by just adding one call to dtrtaat(); somewhere, then I
must license the function under the terms of the GNU GPL as expressed
above.
Sorry, FSF, there's nothing you can do about this.
Yes there is, you just violated copyright law and a copyright license
by doing so and can be sued by the copyright holder for copyright
infrigment.
There is no point in answering the rest of this message since it is
based on erroneous preconditions about copyright law and the GNU GPL.
Cheers.
Graham Murray
> Now, I, Evil Bill Fence Door, copyright this patch, sell it with
> onerous copy protection, and for $1,000,000 a copy. The license
> that comes with it prohibits re-distribution of the patch. Note
> that I'm *not* re-distributing any GPL-licensed software. It's up
> to the customer to get it himself.
But the recipient has no need to re-distribute the patch. Applying the
patch generates a derived work of the software being patched. So, if
the original software is licenced under the GPL then the derived work
will be as well. Therefore the recipient of the patch is allowed,
under the terms of the GPL, the distribute the patched software.
Merijn de Weerd
> Now, I, Evil Bill Fence Door, copyright this patch, sell it with
> onerous copy protection, and for $1,000,000 a copy. The license
> that comes with it prohibits re-distribution of the patch. Note
> that I'm *not* re-distributing any GPL-licensed software.
>
> But you _modified_ a GPL licensed work (section 2 of the GNU GPL), and
> now are distributing the modifications to this work. It is completely
> irrelevant what the form of the patch is, your patch does not work
> without the GPLed work, and cannot be used without it so it is a
> deriviate work.
If I distribute the modifications, then yes. In this example
only *instructions* are provided. Saying "crop the photo so
you see only the face, then put it in a red frame" is not
a derivative work of that photo.
> To create the patch you modified a GPLed work, so it
> is clearly a modification in anyway of the word, how you represent
> these modifications are once again completely irrelevant. Then there
> is the fact that your patch requires the GPLed work to be useful.
That's not the copyright law criterion for a derivative work.
The derivative has to *contain* all or part of the pre-existing
work.
And that is actually what the section of the GPL you quoted
is referring to. If your original code is not derived from
the GPL code, it's a separate independent work. It may _need_
the GPL code to actually do something. That does not make
it a derivative work. An application is not a derivative work of
the operating system, although you need an OS to run the application.
What the GPL says in section 2 is that if you combine your own
work with the GPL work, the GPL applies to the whole. That's
logical: such a combination is a derivative work. This paragraph
of text is my original work. The combination of my paragraphs
with the parts of your message that I cited above is a derivative
work of your message. (I'm allowed to make that derivative work
because of fair use).
Alexander Terekhov
Gordon Burditt wrote:
[...]
> can the customer distribute the *modified version*, but not Evil
> Bill's patch used to create it, and satisfy the GPL? I think the
> answer is yes.
If the license on patch imposes forbearance from "first sale" right
under 17 USC 109, then the answer is "no, or else...". Failure to
fulfill this covenant will breach license agreement and entitle the
lisensor to damages. Customer may still do it though. The contract
laws recognize a concept called "efficient breach" which encourages
breach of a contract if it's economically efficient to do so.
Compliance with a contract is almost always voluntary -- if you
choose not to comply, then you don't have to. You merely have to
compensate the non-breaching party for his expectancy interest.
regards,
alexander.
Alexander Terekhov
"Alfred M. Szmidt" wrote:
>
> > What I trying to say is there ARE some intelligent properties in
> > the patch which we want to keep under our control, but we never
> > want to put any restriction on any one else. So can we protect
> > our own tiny patch not to be public?
>
> As long as those "intelligent properties" in your patch don't
> contain any protected expression (google the AFC test) from the
> GPL'd work you can license those portions of your patch under any
> terms you like.
>
> This is true. But as long as you incoperate those `intelligent
> properties'[0] with a GNU GPLed work, in which case you must license
> them under the GNU GPL.
Sez who? (Besides you and other brainwashed GNUtians, that is.)
I don't care what you say. Thanks to Wallace, the GPL drafter is on
record: <quote> In fact, the GPL itself rejects any automatic
aggregation of software copyrights under the GPL simply because one
program licensed under the GPL is distributed together with another
program that is not licensed under the GPL: "In addition, mere
aggregation of another work not based on the Program with the Program
(or with a work based on the Program) on a volume of a storage or
distribution medium does not bring the other work under the scope of
this License." </quote> http://www.terekhov.de/Wallace_v_FSF_37.pdf
See also http://www.rosenlaw.com/Rosen_Ch06.pdf ("If identifiable
sections of that work are not derived...")
regards,
alexander.
Alexander Terekhov
Graham Murray wrote:
[...]
> But the recipient has no need to re-distribute the patch. Applying the
> patch generates a derived work of the software being patched. So, if
> the original software is licenced under the GPL then the derived work
> will be as well. Therefore the recipient of the patch is allowed,
> under the terms of the GPL, the distribute the patched software.
Derivative work portion of patch (if any) come under the GPL. But
the license of non derivative work portion of patch may prohibit
redistribution of patched software in aggregate as a whole
compilation.
regards,
alexander.
David Kastrup
> Sorry, FSF, there's nothing you can do about this. I don't need a
> license from you to distribute the patch. It's not derived [hint:
> this is a term defined specifically for copyright law] from your
> software, so I don't need your license. The fact that the patch is
> useless without GPL software is irrelevant - that's not the way
> copyright law works. Gas engines are useless without gas, but that
> doesn't mean I need a license from an oil company to sell engines.
Because oil is a substance, not a medium with copyable content.
David Kastrup
> I don't care what you say. Thanks to Wallace, the GPL drafter is on
> record: <quote> In fact, the GPL itself rejects any automatic
> aggregation of software copyrights under the GPL simply because one
> program licensed under the GPL is distributed together with another
> program
"together with" does not describe the relationship of Siamese twins.
Alexander Terekhov
Merijn de Weerd wrote:
[...]
> What the GPL says in section 2 is that if you combine your own
> work with the GPL work, the GPL applies to the whole. That's
> logical: such a combination is a derivative work. This paragraph
> of text is my original work. The combination of my paragraphs
> with the parts of your message that I cited above is a derivative
> work of your message.
Not at all. It's a compilation.
Now, this work is a derivative work of your message:
What the GPL says in section 2 is that if you combine your own
independent work under copyright law with the GPL work, the GPL doesn't
not bring the other work under the scope of the GPL. This combination
of paragraphs with the parts of your message that I cited above is a
compilation and not a derivative work of your message.
And only this work is a derivative work of your message.
Please bare in your mind that <quote> In fact, the GPL itself rejects
any automatic aggregation of software copyrights under the GPL simply
because one program licensed under the GPL is distributed together with
another program that is not licensed under the GPL: "In addition, mere
aggregation of another work not based on the Program with the Program
(or with a work based on the Program) on a volume of a storage or
distribution medium does not bring the other work under the scope of
this License. </quote> http://www.terekhov.de/Wallace_v_FSF_37.pdf
regards,
alexander.
Alexander Terekhov
David Kastrup wrote:
>
> Alexander Terekhov <tere...@web.de> writes:
>
> > I don't care what you say. Thanks to Wallace, the GPL drafter is on
> > record: <quote> In fact, the GPL itself rejects any automatic
> > aggregation of software copyrights under the GPL simply because one
> > program licensed under the GPL is distributed together with another
> > program
>
> "together with" does not describe the relationship of Siamese twins.
And what's the relevance of that remark? Under Berne Convention
software is protected as literary works. The mechanism of linking
is irrelevant.
http://www.catb.org/~esr/Licensing-HOWTO.html
<quote>
consider the case of two scientific papers which reference each other.
The fact that paper B calls paper A (references it for support) does
not make B a derivative work of A. This remains true whether B and A
are published together in a symposium (analogous to static linkage) or
separately (analogous to dynamic linkage). Computer programs are
defined in 17 USC as literary works
</quote>
regards,
alexander.
David Kastrup
> David Kastrup wrote:
>>
>> Alexander Terekhov <tere...@web.de> writes:
>>
>> > I don't care what you say. Thanks to Wallace, the GPL drafter is on
>> > record: <quote> In fact, the GPL itself rejects any automatic
>> > aggregation of software copyrights under the GPL simply because one
>> > program licensed under the GPL is distributed together with another
>> > program
>>
>> "together with" does not describe the relationship of Siamese twins.
>
> And what's the relevance of that remark? Under Berne Convention
> software is protected as literary works. The mechanism of linking
> is irrelevant.
Except that it isn't because you don't link unrelated pieces of
software (well, you can, but that is just aggregating them in one
library). They have to interface.
David Kastrup
> Merijn de Weerd wrote:
> [...]
>> What the GPL says in section 2 is that if you combine your own
>> work with the GPL work, the GPL applies to the whole. That's
>> logical: such a combination is a derivative work. This paragraph
>> of text is my original work. The combination of my paragraphs
>> with the parts of your message that I cited above is a derivative
>> work of your message.
>
> Not at all. It's a compilation.
You are confusing "compilation" in the literary (and legal) and in the
computer sense. A compilation is a collection of independent works
only related by topic. You can throw out parts and retain a
compilation.
Alexander Terekhov
David Kastrup wrote:
>
> Alexander Terekhov <tere...@web.de> writes:
>
> > David Kastrup wrote:
> >>
> >> Alexander Terekhov <tere...@web.de> writes:
> >>
> >> > I don't care what you say. Thanks to Wallace, the GPL drafter is on
> >> > record: <quote> In fact, the GPL itself rejects any automatic
> >> > aggregation of software copyrights under the GPL simply because one
> >> > program licensed under the GPL is distributed together with another
> >> > program
> >>
> >> "together with" does not describe the relationship of Siamese twins.
> >
> > And what's the relevance of that remark? Under Berne Convention
> > software is protected as literary works. The mechanism of linking
> > is irrelevant.
>
> Except that it isn't because you don't link unrelated pieces of
> software (well, you can, but that is just aggregating them in one
> library). They have to interface.
So what? By that standard, a "GPL incompatible" (whatever that means)
email program would violate the copyright law if it downloaded or
send mail from/to a GPL'd mail server. That may well be true in the
GNU Republic, but only in the GNU Republic.
regards,
alexander.
Alexander Terekhov
David Kastrup wrote:
>
> Alexander Terekhov <tere...@web.de> writes:
>
> > Merijn de Weerd wrote:
> > [...]
> >> What the GPL says in section 2 is that if you combine your own
> >> work with the GPL work, the GPL applies to the whole. That's
> >> logical: such a combination is a derivative work. This paragraph
> >> of text is my original work. The combination of my paragraphs
> >> with the parts of your message that I cited above is a derivative
> >> work of your message.
> >
> > Not at all. It's a compilation.
>
> You are confusing "compilation" in the literary (and legal) and in the
> computer sense.
And how am I confusing it?
> A compilation is a collection of independent works
Yes.
> only related by topic.
A "compilation" is a work formed by the collection and assembling of
preexisting materials or of data that are selected, coordinated, or
arranged in such a way that the resulting work as a whole constitutes
an original work of authorship. The term "compilation" includes
collective works.
A "collective work" is a work, such as a periodical issue, anthology,
or encyclopedia, in which a number of contributions, constituting
separate and independent works in themselves, are assembled into a
collective whole.
> You can throw out parts and retain a
> compilation.
And?
regards,
alexander.
Alexander Terekhov
"Alfred M. Szmidt" wrote:
[...]
> Also, the following paragraph might apply:
>
> | These requirements apply to the modified work as a whole. If
> | identifiable sections of that work are not derived from the
> | Program, and can be reasonably considered independent and separate
> | works in themselves, then this License, and its terms, do not
> | apply to those sections when you distribute them as separate
> | works. But when you distribute the same sections as part of a
> | whole which is a work based on the Program, the distribution of
> | the whole must be on the terms of this License, whose permissions
> | for other licensees extend to the entire whole, and thus to each
> | and every part regardless of who wrote it.
A compilation is not "a modified work" (derivative work). Compilations
and derivative works are different concepts under copyright law. And
"that is to say" wording in the GPL Section 0 erroneously misstating
the copyright law has no bearing on the licensees. (The GPL has other
misstatements of copyright law as well and this is just the evidence
that it was written by legally illiterate RMS, not a lawyer.)
There's no dispute that a derivative work as a whole does fall under
the GPL irrespective of who wrote those "sections" (whatever that not
defined term "section" means in the GNU Republic). But then it comes
to aggregating that derivative work ("a work based on the Program")
with "another work not based on the Program", the GPL says that
aggregation "does not bring the other work under the scope of this
License."
"In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of a
storage or distribution medium does not bring the other work under the
scope of this License."
Please bare in your mind that <quote> In fact, the GPL itself rejects
any automatic aggregation of software copyrights under the GPL simply
because one program licensed under the GPL is distributed together with
David Kastrup
> David Kastrup wrote:
>>
>> Alexander Terekhov <tere...@web.de> writes:
>>
>> > David Kastrup wrote:
>> >>
>> >> Alexander Terekhov <tere...@web.de> writes:
>> >>
>> >> > I don't care what you say. Thanks to Wallace, the GPL drafter is on
>> >> > record: <quote> In fact, the GPL itself rejects any automatic
>> >> > aggregation of software copyrights under the GPL simply because one
>> >> > program licensed under the GPL is distributed together with another
>> >> > program
>> >>
>> >> "together with" does not describe the relationship of Siamese twins.
>> >
>> > And what's the relevance of that remark? Under Berne Convention
>> > software is protected as literary works. The mechanism of linking
>> > is irrelevant.
>>
>> Except that it isn't because you don't link unrelated pieces of
>> software (well, you can, but that is just aggregating them in one
>> library). They have to interface.
>
> So what? By that standard, a "GPL incompatible" (whatever that
> means) email program would violate the copyright law if it
> downloaded or send mail from/to a GPL'd mail server.
Uh, no. Because they communicate through a standardized interface not
particular to those programs.
If I pack a statue in a standard rectangular box, I can sell that box
on Ebay afterwards without problems.
If I pack a statue in expanding molding foam, I can't sell the molds
afterwards on Ebay without problems.
> That may well be true in the GNU Republic, but only in the GNU
> Republic.
Which happens to be pretty much every civilized country outside of
Terekhov-lala-land. But I am being redundant.
Alexander Terekhov
David Kastrup wrote:
[...]
> Uh, no. Because they communicate through a standardized interface not
> particular to those programs.
Yeah, and since most of Microsoft's interfaces are not "standardized",
folks at samba (customers aside for a moment) and other projects that
rely on interoperation with and interfacing to MS stuff may well end
up in jail for massive copyright infringement. In the GNU Republic,
that is.
regards,
alexander.
Merijn de Weerd
> Merijn de Weerd wrote:
> [...]
>> What the GPL says in section 2 is that if you combine your own
>> work with the GPL work, the GPL applies to the whole. That's
>> logical: such a combination is a derivative work. This paragraph
>> of text is my original work. The combination of my paragraphs
>> with the parts of your message that I cited above is a derivative
>> work of your message.
>
> Not at all. It's a compilation.
No, it is not. I take parts of someone's message and add
my own message. That is a derivative work. Google Groups
is a compilation.
By selectively quoting parts of another message, I am
creating a derivative. That follows from the literal
wording of 17 USC 101:
A work consisting of editorial revisions, annotations,
elaborations, or other modifications, which, as a whole,
represent an original work of authorship, is a 'derivative work.'
My reply is an original work of authorship. I provided
annotations and other modifications to the message I replied
to. Therefore my reply is and only can be a derivative work.
> Please bare in your mind that <quote> In fact, the GPL itself rejects
> any automatic aggregation of software copyrights under the GPL simply
> because one program licensed under the GPL is distributed together with
Am I distributing my message together with another?
No, I am modifying your message, by retaining parts and rejecting
others. I add "> " to lines of your text and add my own annotations,
criticisms, responses and other creative expressions. So your quote
on the mere aggregation is beside the point. This message is a
derivative of yours. You are now going to make a derivative once
more, no doubt extensively incorporating fair use quotations into
the mix.
And what's more, a compilation consists of a collection of
preexisting works _without creative additions by the collector_. The
creativity required for copyright protection of the compilation lies
in the selection, coordination or arranging of the preexisting works.
"The ten best postings of Alexander Therekhov" is a compilation,
because the criterion "the best" represents creativity on my part.
Merijn de Weerd
> preexisting materials or of data that are selected, coordinated, or
> arranged in such a way that the resulting work as a whole constitutes
> an original work of authorship. The term "compilation" includes
> collective works.
We know you can quote 17 USC. Now can you please _read_ what
you quoted?
Alexander Terekhov
Merijn de Weerd wrote:
[...]
> creating a derivative. That follows from the literal
> wording of 17 USC 101:
>
> A work consisting of editorial revisions, annotations,
> elaborations, or other modifications, which, as a whole,
> represent an original work of authorship, is a 'derivative work.'
>
> My reply is an original work of authorship. I provided
> annotations and other modifications to the message I replied
> to. Therefore my reply is and only can be a derivative work.
You simply don't grok it.
This is a derivative (annotated) work:
Annotation of General Prologue for Canterbury Tales
Whan that [When] Aprill with his shoures soote [sweet showers/rain]
The droghte [drought] of March hath perced [pierced] to the roote [root],
And bathed every veyne in swich licour [fluid such that]
Of which vertu engendred [by virtue of which is caused] is the flour [flower]
Whan Zephirus [Zephir, the West Wind] eek [also] with his sweete breeth [sweet breath]
Inspired hath in every holt and heethด...
But this message as a whole is not a derivative work.
regards,
alexander.
Merijn de Weerd
>> annotations and other modifications to the message I replied
>> to. Therefore my reply is and only can be a derivative work.
>
> You simply don't grok it.
That's nice. Now provide an argument why, please.
> This is a derivative (annotated) work:
True, adding inline annotations produces a derivative work.
Why is a series of citations followed by annotations or responses
not derivative? It's a critique, not a rewrite, but it does
incorporate parts of a preexisting work into a new work.
I don't think there's a single judge who would consider the
style of quoting (inline [] versus ">"-based quoting) at
all relevant.
Alfred M. Szmidt
*instructions* are provided. Saying "crop the photo so you see only
the face, then put it in a red frame" is not a derivative work of
that photo.
All of this is irrelevant. The instructions to crop a photo can be
applied to millions of photos, your instructions on how to modify the
program can only be applied to a single program to have a useful
result. The instructions are the modifications in this case. A patch
by any means is a set of instructions on how to modify something, and
a patch is always a deriviate work since well, it is a patch...
> To create the patch you modified a GPLed work, so it is clearly
> a modification in anyway of the word, how you represent these
> modifications are once again completely irrelevant. Then there
> is the fact that your patch requires the GPLed work to be useful.
That's not the copyright law criterion for a derivative work. The
derivative has to *contain* all or part of the pre-existing work.
And your list of instructions does contain that. You simply choose to
represent the dervivate work in a different form. How it is
represented is not relevant here since your modifications contain
specifc knowledge of the original work.
Merijn de Weerd
> If I distribute the modifications, then yes. In this example only
> *instructions* are provided. Saying "crop the photo so you see only
> the face, then put it in a red frame" is not a derivative work of
> that photo.
>
> All of this is irrelevant. The instructions to crop a photo can be
> applied to millions of photos, your instructions on how to modify the
> program can only be applied to a single program to have a useful
> result. The instructions are the modifications in this case.
No, they are instructions and they do not actually *contain* all
or part of the preexisting work. If there is no trace of the
preexisting work, the instructions by definition cannot be a
derivative work.
I could tell you to go to www.gnu.org/copyleft/gpl.html and copy the
text of article 2(b). That instruction is specific to that document
and really has no useful result when applied to other documents.
In my opinion it's absurd to say that that sentence therefore
is a derivative work of the GPL text.
> A patch
> by any means is a set of instructions on how to modify something, and
> a patch is always a deriviate work since well, it is a patch...
A patch as used by patch(1) is virtually always a derivative, I
agree with you there. But not every HOWTO is a patch(1)-patch.
> That's not the copyright law criterion for a derivative work. The
> derivative has to *contain* all or part of the pre-existing work.
>
> And your list of instructions does contain that. You simply choose to
> represent the dervivate work in a different form.
No, an instruction like "copy the text of article 2(b) of the GPL"
does not _contain_ all or part of the GPL. A patch(1)-style
patch would be more like this:
+
+ b) You must cause any work that you distribute or publish, that in
+ whole or in part contains or is derived from the Program or any part
+ thereof, to be licensed as a whole at no charge to all third parties
+ under the terms of this License.
+
That _does_ contain parts of the GPL.
> How it is
> represented is not relevant here since your modifications contain
> specifc knowledge of the original work.
A set of instructions on how to modify do not always actually
_contain_ the modifications. The text "dDelete paragraph 3" does
not contain anything _from_ paragraph 3.
I'll immediately admit that this is a trick that circumvents
the intent of the GPL. Judges may frown on tricks, true. But
that does not make instructions the same as patches.
Merijn
PS: no need to cc me when replying
Alfred M. Szmidt
> be applied to millions of photos, your instructions on how to
> modify the program can only be applied to a single program to
> have a useful result. The instructions are the modifications in
> this case.
No, they are instructions and they do not actually *contain* all or
part of the preexisting work. If there is no trace of the
preexisting work, the instructions by definition cannot be a
derivative work.
The instructions on where to modify are the trace.
Merijn de Weerd
> part of the preexisting work. If there is no trace of the
> preexisting work, the instructions by definition cannot be a
> derivative work.
>
> The instructions on where to modify are the trace.
Well, since you snipped my arguments and explanations without
even bothering to explain why they don't apply, let me just say:
no, you are wrong.
Merijn
Alfred M. Szmidt
> all or part of the preexisting work. If there is no trace of
> the preexisting work, the instructions by definition cannot be
> a derivative work.
>
> The instructions on where to modify are the trace.
Well, since you snipped my arguments and explanations without even
bothering to explain why they don't apply, let me just say: no, you
are wrong.
No, you are wrong. Please read some basic copyright law. You haven't
even bothered opening any law codex so it is a waste of my time to
explain such basic things to you, sorry.
Merijn de Weerd
> even bothered opening any law codex so it is a waste of my time to
> explain such basic things to you, sorry.
It's always nice to see people resulting to insults when they
ran out of arguments. You know nothing about me or my (copyright
law student) background.
At least I know the difference between telling people "please
make a copy of page 6" and giving them a copy. That's good
enough for my professor. If it's not good enough for you, tough.
Alfred M. Szmidt
> haven't even bothered opening any law codex so it is a waste of
> my time to explain such basic things to you, sorry.
It's always nice to see people resulting to insults when they ran
out of arguments. You know nothing about me or my (copyright law
student) background.
Please look up in a dictionary what constitutes an insult, and how it
is different from not wanting to waste my time with quibbling with
people who are to lazy to read law codexes.
At least I know the difference between telling people "please make
a copy of page 6" and giving them a copy. That's good enough for my
professor. If it's not good enough for you, tough.
Once again you confuse oranges with stones. `copy page 6' can be
applied to any book/article/essay/etc that is >= 6 pages long and you
will get a useful result. `Add foo at line 1, 5, 7. Remove line 7,
8, 10' cannot produce an useful result for all or even most works, it
can only produce something useful for a very limited range (and that
range grows smaller the more instructions you have about where to
modify the work in questions), and this is clearly a deriviate since
it is clearly based on a different work. That you do not actually
refer to the specific parts by name is completely and utterly
irrelevant.
This is my last message on the subject with you.
Miles Bader
> At least I know the difference between telling people "please
> make a copy of page 6" and giving them a copy. That's good
> enough for my professor. If it's not good enough for you, tough.
Of course, saying "tough" won't work very well with a judge... (whatever
your professor may think)
-Miles
--
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.
Gordon Burditt
> onerous copy protection, and for $1,000,000 a copy. The license
> that comes with it prohibits re-distribution of the patch. Note
> that I'm *not* re-distributing any GPL-licensed software.
>
>But you _modified_ a GPL licensed work (section 2 of the GNU GPL), and
>now are distributing the modifications to this work. It is completely
>irrelevant what the form of the patch is, your patch does not work
>without the GPLed work, and cannot be used without it so it is a
>deriviate work.
Copyright law defines no such thing as a "deriviate work".
Copyright law and the GPL define a "derivative work", and
this definition has nothing to do with your definition of it.
The GPL Version 2 contains:
>The "Program", below,
>refers to any such program or work, and a "work based on the Program"
>means either the Program or any derivative work under copyright law:
>that is to say, a work containing the Program or a portion of it,
>either verbatim or with modifications and/or translated into another
>language. (Hereinafter, translation is included without limitation in
>the term "modification".) Each licensee is addressed as "you".
A derivative work is a work *CONTAINING THE PROGRAM OR A PORTION OF IT*.
Now, most *real* patches, especially context diffs, contain a portion
of the program to be patched. But you can come up with patches
that don't. "diff -e" does a pretty good job if the lines added are
completely new and not modified lines from the original program.
Incidentally, you can apply a diff -e patch to any file with a sufficient
number of lines. I didn't say the result would be useful, but the
GPL definition of "derivative work" says nothing about it being useful.
Gordon L. Burditt
Alexander Terekhov
Incorporating (parts of a) preexisting work into a new work is
not sufficient criterion to distinguish derivative works from
compilations. Both types of work employ preexisting material.
At this point, I'll just let you sort it out with your
professor. But you are quite correct that the issue of ">"-
based quoting is irrelevant. I just wonder why did you bring
this issue in one of your previous messages. You're also wrong
that "compilation consists of a collection of preexisting works
_without creative additions by the collector_". A collector
may well author a separate and independent work(s) (like
inroduction, preface, etc.) and include it in his compilation
just like all other separate and independent works.
regards,
alexander.
Alexander Terekhov
Gordon Burditt wrote:
>
> > Now, I, Evil Bill Fence Door, copyright this patch, sell it with
> > onerous copy protection, and for $1,000,000 a copy. The license
> > that comes with it prohibits re-distribution of the patch. Note
> > that I'm *not* re-distributing any GPL-licensed software.
> >
> >But you _modified_ a GPL licensed work (section 2 of the GNU GPL), and
Section 2 of the GPL says that a derivative work (under copyright law)
as a whole can be (sub)licensed to third parties under the GPL and only
the GPL. Not all works "based on" (colloquially) on the GPL'd work are
derivative works under copyright law. A patch which doesn't contain any
protected expression from the GPL'd work is NOT a derivative work under
copyright law. Section 2 of the GPL also says that aggregating GPL
original or derivative work ("a work based on the Program") with
"another work not based on the Program ... does not bring the other
work under the scope of this License."
> >now are distributing the modifications to this work. It is completely
> >irrelevant what the form of the patch is, your patch does not work
> >without the GPLed work, and cannot be used without it so it is a
> >deriviate work.
>
> Copyright law defines no such thing as a "deriviate work".
> Copyright law and the GPL define a "derivative work", and
The GPL doesn't define derivative works. It explicitly defers to
(US) copyright law (and hence implicitly to case law interpreting the
statute) and merely misstates the copyright law in "that is to say"
wording about "work based on the Program" being "either the Program or
any derivative work under copyright law". Erroneous misstatements of
referred statute by the GPL drafter has no bearing on the licensees.
regards,
alexander.