Would anyone be interested in forming such a pool? I am willing to wait
years for this to be resolved through certain organizations, but I
believe we can do better.
Last I checked, I have 1 long-time poster of this list on board. Would
anyone else like to join? Ideally I'd like to get the LKML (which I have
CC'd) involved so that authors of critical Linux components be a part of
this. I'm not sure if my defconfig commits to Android kernel branches
count as contributions, so I'm not going to consider myself a Linux
contributor unless told otherwise.
This pool would be used in the following manner:
* Formally requesting source for binaries (means to request source
* Formally requesting removal of critical copyrighted code that Linux
cannot function without
* Informing interested parties with respect to refusals of the above
The CTO of Anthrax's hosting server is very interested in terminating
Chad Goodman's account. Bullet point #3 might come into effect here.
If this is a bad idea, uses incorrect logic, or does not follow the
conventions of GPL enforcement, feel free to shoot this idea down with
utmost prejudice.
- Eric
On 5/18/2013 3:24 AM, Eric Appleman wrote:
> Would anyone be interested in forming such a pool? I am willing to
> wait years for this to be resolved through certain organizations, but
> I believe we can do better.
>
> Last I checked, I have 1 long-time poster of this list on board. Would
> anyone else like to join? Ideally I'd like to get the LKML (which I
> have CC'd) involved so that authors of critical Linux components be a
> part of this. I'm not sure if my defconfig commits to Android kernel
> branches count as contributions, so I'm not going to consider myself a
> Linux contributor unless told otherwise.
>
> This pool would be used in the following manner:
>
> * Formally requesting source for binaries (means to request source
> * Formally requesting removal of critical copyrighted code that Linux
> cannot function without
> * Informing interested parties with respect to refusals of the above
>
> The CTO of Anthrax's hosting server is very interested in terminating
> Chad Goodman's account. Bullet point #3 might come into effect here.
>
> If this is a bad idea, uses incorrect logic, or does not follow the
> conventions of GPL enforcement, feel free to shoot this idea down with
> utmost prejudice.
>
> - Eric
Forgot to add background on Anthrax Kernels and their violations:
http://pastebin.com/X5Cciy03
- Eric
On Sat, May 18, 2013 at 8:24 AM, Eric Appleman <[email protected]> wrote:
> Would anyone be interested in forming such a pool?
count me in.
> Last I checked, I have 1 long-time poster of this list on board. Would
> anyone else like to join? Ideally I'd like to get the LKML (which I have
> CC'd) involved so that authors of critical Linux components be a part of
> this. I'm not sure if my defconfig commits to Android kernel branches count
> as contributions,
even if you did not explicitly put "Copyright (C) {your name}" in
them, you still retain copyright. depending on the country you are in
you cannot even get rid of the copyright even if you say "i forever
renounce irrevocably and without restriction or limitation all
copyright and place this into the public domain signed me" - you have
to actively assign the copyright to someone else.
> so I'm not going to consider myself a Linux contributor
> unless told otherwise.
you wrote something that's copyrighted. therefore you're a copyright
holder [therefore automatically any copyright violator must request
your permission to have their GPLv2 license rights reinstated].
my linux kernel modifications are small, too - they sort of winged
their way by a slow process of migration into tmpfs by way of selinux
xattrs. and there are likely some unattributed contributions that
came from the xanadux.sf.net project originally (depending on whether
they were picked up or not over time)
but that makes no odds: i am still a copyright holder, ergo a
contributor, ergo i'd like to be included in the pool please.
> This pool would be used in the following manner:
>
> * Formally requesting source for binaries (means to request source
> * Formally requesting removal of critical copyrighted code that Linux cannot
> function without
> * Informing interested parties with respect to refusals of the above
it would also serve as a useful point of contact for criminal
copyright violators wishing to have their license rights reinstated.
also it would serve as a good starting point to be able to contact
large numbers of people wishing to explicitly dual-license their code
contributions to the linux kernel.
actually, that's a good point. please can it be specifically noted,
from this moment onwards, that all contributions that i have made to
the linux kernel are dual-licensed under both the GPLv2 and also the
GPLv3+ license?
someone has to start somewhere on this. it doesn't matter if it takes
20 years for all GPLv2-exlusive contributions to be made obselete,
deleted or replaced: a start has to be made.
question: what is the procedure for having that licensing explicitly
added to the linux kernel sources?
l.
On Sun, May 19, 2013 at 12:03 AM, Cole Johnson
<[email protected]> wrote:
>> question: what is the procedure for having that licensing explicitly
>
> added to the linux kernel sources?
>
> IIRC Linus said he will NOT use the GPLv3 for the kernel.
mr linus torvalds is one person. he is not a god. he does not
dictate that which everyone else can choose to do. if mr linus
torvalds is telling everyone "he will not use the GPLv3 for the
kernel" i.e. NOBODY may dual-license their copyright material in the
linux kernel then he is *MASSIVELY* overstepping a serious boundary of
both propriety and copyright law. if i choose to release all
copyright code under dual licenses then THAT IS MY RIGHT AND NO FUCKER
IS GOING TO TELL ME OTHERWISE.
so, let's nip this in the bud and set it straight, ok?
i assume that what mr linus torvalds *meant* to say was "i have some
code, it is under my copyright. i personally choose not to release
that copyright material under any license other than the GPLv2 and
that is my choice and my right as the owner of that copyright
material. signed, mr linus torvalds".
that choice - made by mr linus torvalds - has *nothing to do with
anybody else's choice*.
so the question remains, and i'd like an answer: what is the
procedure for formally adding to the linux kernel that my copyrighted
material is dual-licensed under both the GPLv2 and the GPLv3+? do i
submit a patch, and is it as simple as that?
unless.... unless what mr linus torvalds meant to say was, "i don't
like the GPLv3+ license. if any fucker wants to release linux kernel
code under the GPLv3+ (as well as the GPLv2), they can fuck off. in
fact, they will be banned from submitting contributions that are not
specifically GPLv2. if they try to dual-license their code, it will
not be accepted. i, linus torvalds, have spoken". which i seriously
seriously doubt, but there seems to be some implication that that's
the case, here.
> If a company
> begins TiVoization, that's up to them. The kernel should allow that.
well, it will continue to be "allowed" for many many years, even if
people dual-license their code in the linux kernel.
l.
On Sun, May 19, 2013 at 10:12 AM, Ian Stirling <[email protected]> wrote:
> On 18.05.2013 19:27, luke.leighton wrote:
>
>> question: what is the procedure for having that licensing explicitly
>> added to the linux kernel sources?
>
>
> Fork the kernel, and put it up on a repo somewhere that says you're trying
> to get it all as
> GPL3.
pay me $100k per year to set up a foundation which maintains that
code and i will do so.
not going to happen, is it ian? i was initially quite pissed at the
rest of what you wrote, especially at its sarcasm. but then it
occurred to me that it is highly indicative of a feeling of
dis-empowerment that everyone feels in the linux kernel community.
you felt - ian - that what i want to do cannot be done by *anyone* -
presumably because Linus Has Spoken. or perhaps because the scale of
the task is beyond you.
but i'm not interested in any of that. i've made a decision. and my
question was very very specific.
i wish to know the procedure by which my formally and publicly
announced release of all linux kernel contributions under the dual
licenses of GPLv2 and GPLv3+ may be entered - formally - upstream and
into the linux kernel sources being maintained on git.kernel.org
i don't give a fuck about what anybody else may choose; i do not give
a fuck about the timescales. i want *MY* choice to be respected: *MY*
code contributions under the GPLv2 and GPLv3+ and have that properly
recorded.
so. could someone please inform me what the procedure is: is it as
simple as submitting a patch?
l.
Hi Luke,
> if i choose to release all copyright code under dual licenses then
> THAT IS MY RIGHT
Sssh! It's a Sunday morning; hangover time for many.
Does the LICENSING section in
http://lxr.free-electrons.com/source/Documentation/development-process/1.Intro#L237
help?
Cheers, Ralph.
On Sun, May 19, 2013 at 12:39 PM, luke.leighton <[email protected]> wrote:
> On Sun, May 19, 2013 at 12:03 AM, Cole Johnson
> <[email protected]> wrote:
>>> question: what is the procedure for having that licensing explicitly
>>
>> added to the linux kernel sources?
>>
>> IIRC Linus said he will NOT use the GPLv3 for the kernel.
>
> mr linus torvalds is one person. he is not a god. he does not
> dictate that which everyone else can choose to do. if mr linus
> torvalds is telling everyone "he will not use the GPLv3 for the
> kernel" i.e. NOBODY may dual-license their copyright material in the
> linux kernel then he is *MASSIVELY* overstepping a serious boundary of
> both propriety and copyright law. if i choose to release all
> copyright code under dual licenses then THAT IS MY RIGHT AND NO FUCKER
> IS GOING TO TELL ME OTHERWISE.
>
> so, let's nip this in the bud and set it straight, ok?
>
> i assume that what mr linus torvalds *meant* to say was "i have some
> code, it is under my copyright. i personally choose not to release
> that copyright material under any license other than the GPLv2 and
> that is my choice and my right as the owner of that copyright
> material. signed, mr linus torvalds".
>
> that choice - made by mr linus torvalds - has *nothing to do with
> anybody else's choice*.
>
> so the question remains, and i'd like an answer: what is the
> procedure for formally adding to the linux kernel that my copyrighted
> material is dual-licensed under both the GPLv2 and the GPLv3+? do i
> submit a patch, and is it as simple as that?
>
> unless.... unless what mr linus torvalds meant to say was, "i don't
> like the GPLv3+ license. if any fucker wants to release linux kernel
> code under the GPLv3+ (as well as the GPLv2), they can fuck off. in
> fact, they will be banned from submitting contributions that are not
> specifically GPLv2. if they try to dual-license their code, it will
> not be accepted. i, linus torvalds, have spoken". which i seriously
> seriously doubt, but there seems to be some implication that that's
> the case, here.
But dual license means the license taker may chose which license to
apply, not that you can dictate which one to use. And as long as any
part of the kernel is GPLv2 (no +), (s)he can't choose anything except
GPLv2, as GPLv2 and GPLv3 are incompatible.
So any further licenses will never apply to any use in the kernel.
Only if somebody took your code out of the kernel and used it in a
separate GPLv3+ project, then the GPLv3+ license could and would
apply.
Also GPLv2 + GPLv3+ == GPLv2+. And there are already plenty of
examples in the kernel that are GPLv2+ licensed (try searching for "or
later").
Jonas
On Sun, May 19, 2013 at 12:04 PM, Ralph Corderoy <[email protected]> wrote:
> Hi Luke,
>
>> if i choose to release all copyright code under dual licenses then
>> THAT IS MY RIGHT
>
> Sssh! It's a Sunday morning; hangover time for many.
:) *sotto voice* sorry.
> Does the LICENSING section in
> http://lxr.free-electrons.com/source/Documentation/development-process/1.Intro#L237
> help?
it does in some ways. it doesn't answer the specific question, "how
do i formally get my copyright announcement updated in the linux
kernel source code" yet though but it does provide some opportunity to
point out some errors and mis-... mis-somethings, i can't think of the
exact word.
252 One implication of this ownership structure is that any attempt to change
253 the licensing of the kernel is doomed to almost certain failure.
interesting. this statement completely and utterly misses the point.
it assumes that "the kernel" and "the license" are directly and
irrevocably linked. which they most certainly are not.
the statement *should* read as follows:
"any attempt to change the licensing on the files which make up the
linux kernel"
which, again is mis-leading - in this case very very badly - because
it implies that somehow just because *most* of the files are under one
license, therefore automatically people should not make their *own*
mind - their own free and conscious choice - to release their
contributions under alternative licenses.
i could give half a dozen examples, here, including many books and
films, documentaries, sports achievement stories and so on, all of
which are along the lines of, "person decides to break
mould/boundaries/tradition, gets told by priests/politicians/peers
it's not possible, distance/time/resources are too far/long/small
therefore you will fail/die/get-strung-up-for-heresy, they do it
anyway, and everyone goes hurrah at the end".
let's make another attempt:
"we the major linux copyright holders, who wrote this documentation,
respect your decision to choose an additional license as well as the
GPLv2 to release your code under, and it is important to make it clear
that we do not seek to influence your right to choose an additional
license or licenses, one way or the other. the key to remember is
that any files released under licenses *not* compatible with the GPLv2
*CANNOT* legally be used. as the kernel is an aggregated work, over
time the accumulation of files under alternative licenses (those that
are compatible with the current GPLv2 license) *may* result in a
useful and useable subset of the linux kernel source files coming
about. so our personal opinion here - which should in no way
influence your own decisions - is that you are pissing in the wind if
you think that's going to come about any time soon, and as a result of
that, we (the major linux copyright holders who wrote this
documentation) decided not to bother releasing our contributions under
any license other than the GPLv2."
253 There are
254 few practical scenarios where the agreement of all copyright holders could
255 be obtained
one such scenario would be to have a pool of individuals and entities
that maintain a subscription to a list such that their permission -
collectively - could be sought. if there are some individuals or
entities that have begun the process, others may be more inclined to
follow.
but even there, it's still not the point:
255 (or their code removed from the kernel).
i'm intrigued that there has been no mention of rewrites. at some
point in the future, if there happens to be all but a critical but
tiny subset under an alternative license, surely someone would step up
and do a rewrite, yes?
255
So, in particular,
256 there is no prospect of a migration to version 3 of the GPL in the
257 foreseeable future.
"forseeable future". is that a good reason to not take action??
"we're stuck here therefore we should not move" - how many
civilisations have died out exactly because of that kind of thinking??
assuming we don't blow up the planet within 50-100 years, is it
reasonable to assume that in 50-100 years - and this is a sincere
question absolutely no dis-integrity here - is it reasonable to start
the process now such that linux in 50 to 100 years time is useable
under an alternative license?
overall i see this entire paragraph as deeply flawed, full of
assumptions, and thoroughly defeatist. i'm surprised that the
attention to detail normally inherent in linux kernel programming
hasn't been applied across the board.
l.
On Sun, May 19, 2013 at 12:19 PM, Jonas Gorski
<[email protected]> wrote:
> But dual license means the license taker may chose which license to
> apply, not that you can dictate which one to use.
yes.
> And as long as any
> part of the kernel is GPLv2 (no +), (s)he can't choose anything except
> GPLv2, as GPLv2 and GPLv3 are incompatible.
that doesn't sound right. actually, this is a very very important
misunderstanding, jonas.
you *can* choose GPLv3 code. what you can choose is: *only* those
files of the linux kernel that are released under GPLv3.
pseudo-algorithm in bash script and maybe a bit of python:
$ filenames_gplv3 = `find . | xargs grep -l GPLv3`
$ filenames_gplv2 = `find . | xargs grep -l GPLv2`
$ files_to_delete = []
$ for x in filenames_gplv2:
if x not in filenames_gplv2:
files_to_delete.append(x)
$ for x in files_to_delete:
rm $x
after that procedure is done, _then_ try doing a kernel compile, see
how far you get.
many people point out that just because this is unlikely to result in
success any time in the next 100 years, that nobody should bother even
starting.
> So any further licenses will never apply to any use in the kernel.
incorrect!! logical assertion error!! :) assert(ELOGICALCONCLUSIONBRAINFART)
> Only if somebody took your code out of the kernel and used it in a
> separate GPLv3+ project, then the GPLv3+ license could and would
> apply.
after reviewing the above pseudo-code i believe you'll agree that
that's slightly misleading. one could also choose to leave the files
in-place in the *same* project's source tree, and just not use any of
the ones that were incompatibly-licensed.
> Also GPLv2 + GPLv3+ == GPLv2+. And there are already plenty of
> examples in the kernel that are GPLv2+ licensed (try searching for "or
> later").
very good point, jonas.
l.
On Sun, May 19, 2013 at 2:34 PM, luke.leighton <[email protected]> wrote:
> On Sun, May 19, 2013 at 12:19 PM, Jonas Gorski
> <[email protected]> wrote:
>
>> But dual license means the license taker may chose which license to
>> apply, not that you can dictate which one to use.
>
> yes.
>
>> And as long as any
>> part of the kernel is GPLv2 (no +), (s)he can't choose anything except
>> GPLv2, as GPLv2 and GPLv3 are incompatible.
>
> that doesn't sound right. actually, this is a very very important
> misunderstanding, jonas.
>
> you *can* choose GPLv3 code. what you can choose is: *only* those
> files of the linux kernel that are released under GPLv3.
>
>
> pseudo-algorithm in bash script and maybe a bit of python:
>
> $ filenames_gplv3 = `find . | xargs grep -l GPLv3`
> $ filenames_gplv2 = `find . | xargs grep -l GPLv2`
> $ files_to_delete = []
> $ for x in filenames_gplv2:
> if x not in filenames_gplv2:
> files_to_delete.append(x)
> $ for x in files_to_delete:
> rm $x
>
> after that procedure is done, _then_ try doing a kernel compile, see
> how far you get.
This will produce an empty directory.
There are 0 files released under GPLv3 (because its incompatible with
GPLv2). There are some release under GPLv2+, but this is mostly
drivers and architecture specific code, and a collection of drivers
does not make a kernel.
Almost nothing of the parts that define a kernel (like memory and
process management) are GPLv2+. Therefore I say the kernel will always
be GPLv2, no matter how many files you *add* that are GPLv2+.
> many people point out that just because this is unlikely to result in
> success any time in the next 100 years, that nobody should bother even
> starting.
Because Linus /is/ the highest authority regarding Linux. He holds the
copyright to the most crucial parts, and without his cooperation, you
will never get the GPLv2 parts to be re-licensed to GPLv2+, unless you
remove everything from him and replace it with your own
implementations. And do the same with every other contributors' code
who doesn't agree to switch to GPLv2+.
>> So any further licenses will never apply to any use in the kernel.
>
> incorrect!! logical assertion error!! :) assert(ELOGICALCONCLUSIONBRAINFART)
>
>> Only if somebody took your code out of the kernel and used it in a
>> separate GPLv3+ project, then the GPLv3+ license could and would
>> apply.
>
> after reviewing the above pseudo-code i believe you'll agree that
> that's slightly misleading. one could also choose to leave the files
> in-place in the *same* project's source tree, and just not use any of
> the ones that were incompatibly-licensed.
Have fun with that. That isn't a kernel any more, that's a loose
collection of drivers and architecture support code.
You will have to re-invent every GPLv2 only part they link
against/require, or rewrite the GPLv2+ code to not use it. And if you
finally got it to work, it has already become a separate project as it
won't have much resemblance with the Linux kernel any more. ;-)
Also no company will ever bother to do that, because choosing GPLv3
will only bring disadvantages to them. And writing their own kernel/OS
will likely be less work and more rewarding, because then they own the
copyright for it and can choose any license they want.
Jonas
On Sun, May 19, 2013 at 03:28:28PM +0200, Jonas Gorski wrote:
> Because Linus /is/ the highest authority regarding Linux. He holds the
> copyright to the most crucial parts, and without his cooperation, you
> will never get the GPLv2 parts to be re-licensed to GPLv2+, unless you
> remove everything from him and replace it with your own
> implementations. And do the same with every other contributors' code
> who doesn't agree to switch to GPLv2+.
It's not just Linus; many senior Linux kernel developers have spoken
very clearly that the anti-Tivoization clause in GPLv3 is totally
unacceptable, and so many of us have stated unequivocally that our
code will be released under a GPLv2-only license. This means that
GPLv3-only code is always going to be incompatible with code released
as part of the Linux kernel, because substantial parts of the kernel
have and will be available only under a GPLv2 only license.
If anyone wants to release their code under a dual-license, it's
easist if that's how you submitted the code originally. For example,
drivers/char/random.c is released under a BSD/GPLv2 dual license
(because I wanted to encourage its use in other operating systems,
since to me high quality crypto is more important that free software
wankery/idealism).
If you have only contributed a few lines or partially to a particular
single file, specifying that "these 15 linues of the function
I_worship_at_the_altar_of_rms() are under the GPLv2/v3, even through
the rest of the file is GPLv2-only" is not something that we generally
do. Speaking as a subsystem maintainer, for the portions of the code
that I maintain, if someone insisted on line-level copyright
statements, I'd just simply reject the patch rather than dealing with
the accounting nightmare.
If you want to add a GPLv2/GPLv3 dual license to a file which you
originally contributed to, but then later on other peoeple have
contributed lines of code, you'll need to get the consent of everyone
who have contributed changes to that file.
Finally, as Jonas has stated, if you are trying to impose the
anti-Tivoization clause through the back door, it's not going to have
that effect, since people can always choose either license for
dual-licensed code, and for the kernel GPLv2 always has to be one of
the choices. The only reason why you might want to dual-license the
code is if you want to allow said code to be used in other contexts,
either in BSD-licensed code in the case of a GPLv2/BSD dual license,
or GPLv3-only licensed code in the case of a GPLv2/GPLv3 dual license.
Regards,
- Ted
On 05/19/2013 06:57 AM, luke.leighton wrote:
> On Sun, May 19, 2013 at 10:12 AM, Ian Stirling <[email protected]> wrote:
>> On 18.05.2013 19:27, luke.leighton wrote:
>>
>>> question: what is the procedure for having that licensing explicitly
>>> added to the linux kernel sources?
[snip license compatibility argument /]
> i don't give a fuck about what anybody else may choose; i do not give
> a fuck about the timescales. i want *MY* choice to be respected: *MY*
> code contributions under the GPLv2 and GPLv3+ and have that properly
> recorded.
You seem to be under some misunderstanding about the kernel community's
obligations to you. Their only obligation is to respect your copyright
as you submitted your changes. (Signed-off-by === GPLv2 compatible).
The GPL is designed for its provisions to take effect at the point of
distribution.
Each contributor is choosing to publish/distribute through Linus. Linus
chooses to publish/distribute via kernel.org under the trademarked name
"Linux". Most distributions publish their own kernels, but choose to
base them on Linus' kernel for economies of scale.
If you don't like what any of the above choose to publish/distribute,
you may publish/distribute the code yourself, provided you respect the
other contributors' licenses.
> so. could someone please inform me what the procedure is: is it as
> simple as submitting a patch?
You can submit a patch. The kernel community is not obligated to accept
it. If you want to be sure your license choice is "properly recorded",
publish it yourself.
Phil
On Sun, May 19, 2013 at 6:39 AM, luke.leighton <[email protected]> wrote:
> mr linus torvalds is one person. he is not a god. he does not
> dictate that which everyone else can choose to do. if mr linus
> torvalds is telling everyone "he will not use the GPLv3 for the
> kernel" i.e. NOBODY may dual-license their copyright material in the
> linux kernel then he is *MASSIVELY* overstepping a serious boundary of
> both propriety and copyright law. if i choose to release all
> copyright code under dual licenses then THAT IS MY RIGHT AND NO FUCKER
> IS GOING TO TELL ME OTHERWISE.
Well that's all well and good, but you couldn't place GPLv3 code
into the kernel, soooooooo. There's not much point in dual licensing
it when it could never be utilized in that manner.
> so, let's nip this in the bud and set it straight, ok?
>
> i assume that what mr linus torvalds *meant* to say was "i have some
> code, it is under my copyright. i personally choose not to release
> that copyright material under any license other than the GPLv2 and
> that is my choice and my right as the owner of that copyright
> material. signed, mr linus torvalds".
And gplv3 code would be incompatible with the license, so, no, you
couldn't add code to the Linux kernel under the GPLv3. Write a new
kernel, and go house I suppose.
> that choice - made by mr linus torvalds - has *nothing to do with
> anybody else's choice*.
Except, the Linux kernel is the code we're talking about here. So
yes, their choices on what to do with his code (and many others code)
DOES has something to do with the original authors choice.
> so the question remains, and i'd like an answer: what is the
> procedure for formally adding to the linux kernel that my copyrighted
> material is dual-licensed under both the GPLv2 and the GPLv3+? do i
> submit a patch, and is it as simple as that?
You submit a patch, it is reviewed, and may or may not be included.
And with the GPLv3 provision, it will not be accepted.
> unless.... unless what mr linus torvalds meant to say was, "i don't
> like the GPLv3+ license. if any fucker wants to release linux kernel
> code under the GPLv3+ (as well as the GPLv2), they can fuck off. in
> fact, they will be banned from submitting contributions that are not
> specifically GPLv2. if they try to dual-license their code, it will
> not be accepted. i, linus torvalds, have spoken". which i seriously
> seriously doubt, but there seems to be some implication that that's
> the case, here.
Soooooo, you don't want your code in his kernel then, do you.
> well, it will continue to be "allowed" for many many years, even if
> people dual-license their code in the linux kernel.
*sigh* Point to a single line of GPLv3 code in the current kernel.
--
-- Thomas
On Sun, May 19, 2013 at 8:24 AM, luke.leighton <[email protected]> wrote:
> it does in some ways. it doesn't answer the specific question, "how
> do i formally get my copyright announcement updated in the linux
> kernel source code" yet though but it does provide some opportunity to
> point out some errors and mis-... mis-somethings, i can't think of the
> exact word.
You submit a patch which will be peer reviewed, and will be rejected
I suspect.
> interesting. this statement completely and utterly misses the point.
> it assumes that "the kernel" and "the license" are directly and
> irrevocably linked. which they most certainly are not.
....... Yes they are. You only have the code due to the license,
and once licences, the license cannot be terminated (the irrevocable
part)
> which, again is mis-leading - in this case very very badly - because
> it implies that somehow just because *most* of the files are under one
> license, therefore automatically people should not make their *own*
> mind - their own free and conscious choice - to release their
> contributions under alternative licenses.
Do you have ANY idea what your talking about? As this point, it
seems like your just making stuff up for the sake of the argument.
> "we the major linux copyright holders, who wrote this documentation,
> respect your decision to choose an additional license as well as the
> GPLv2 to release your code under, and it is important to make it clear
> that we do not seek to influence your right to choose an additional
> license or licenses, one way or the other. the key to remember is
> that any files released under licenses *not* compatible with the GPLv2
> *CANNOT* legally be used.
> as the kernel is an aggregated work, over
> time the accumulation of files under alternative licenses (those that
> are compatible with the current GPLv2 license) *may* result in a
> useful and useable subset of the linux kernel source files coming
> about. so our personal opinion here - which should in no way
> influence your own decisions - is that you are pissing in the wind if
> you think that's going to come about any time soon, and as a result of
> that, we (the major linux copyright holders who wrote this
> documentation) decided not to bother releasing our contributions under
> any license other than the GPLv2."
Nothing stops anyone from releasing their files all by themselves
under whatever license they choose. However incompatible dual
licenses would end up not being accepted, and not becoming part of
Linux.
Thomas
On Sun, May 19, 2013 at 8:34 AM, luke.leighton <[email protected]> wrote:
> On Sun, May 19, 2013 at 12:19 PM, Jonas Gorski
> <[email protected]> wrote:
> that doesn't sound right. actually, this is a very very important
> misunderstanding, jonas.
>
> you *can* choose GPLv3 code. what you can choose is: *only* those
> files of the linux kernel that are released under GPLv3.
No,, you can't. The second you do, you cannot use the GPLv2 code
with it *AT ALL*, making the code you chose to use for the GPLv3
worthless when used in conjunction with the kernel itself. As such,
when you say, "I'm accepting the GPLv3 for this file", you need to now
immediately take that file, move it OUT of the kernel source tree, and
use it for whatever you like, but not under the Linux kernel, making
it, for the most part, worthless to you unless you are writing your
own software.
> many people point out that just because this is unlikely to result in
> success any time in the next 100 years, that nobody should bother even
> starting.
Go house, but make sure to delete any GPLv2 code. I suspect you'll
find you'll have a really hard time, as you won't have a kernel.
>> So any further licenses will never apply to any use in the kernel.
>
> incorrect!! logical assertion error!! :) assert(ELOGICALCONCLUSIONBRAINFART)
You go house, as your one guy making assertions on the Linux kernel
which has been supported and under active development for over 21
years now.
>> Only if somebody took your code out of the kernel and used it in a
>> separate GPLv3+ project, then the GPLv3+ license could and would
>> apply.
>
> after reviewing the above pseudo-code i believe you'll agree that
> that's slightly misleading. one could also choose to leave the files
> in-place in the *same* project's source tree, and just not use any of
> the ones that were incompatibly-licensed.
Correct, except that the kernel, the thing that actually *IS* the
software, won't exist in your tree any longer.
Thomas
On 19.05.2013 11:57, luke.leighton wrote:
> On Sun, May 19, 2013 at 10:12 AM, Ian Stirling
> <[email protected]> wrote:
>> On 18.05.2013 19:27, luke.leighton wrote:
>>
>>> question: what is the procedure for having that licensing
>>> explicitly
>>> added to the linux kernel sources?
>>
>>
>> Fork the kernel, and put it up on a repo somewhere that says you're
>> trying
>> to get it all as
>> GPL3.
<snip>
>
> i wish to know the procedure by which my formally and publicly
> announced release of all linux kernel contributions under the dual
> licenses of GPLv2 and GPLv3+ may be entered - formally - upstream and
> into the linux kernel sources being maintained on git.kernel.org
Umm - that was my point - though I did not make it explicitly.
Either there is a policy change, and it is decided to allow such
dual-licenced code in the repo, or your code does not get checked in,
as it does not have a compatible licence.
If Linus takes the view that he does not wish to allow this - and the
project is not forked - you actually have to do the above.
Sure - you have the right to licence code you write any way you choose.
Linus (and the people involved in maintaining the kernel) have the
right
to not accept your code under that licence.
On Mon, May 20, 2013 at 11:24:02AM +0100, Ian Stirling wrote:
> >i wish to know the procedure by which my formally and publicly
> >announced release of all linux kernel contributions under the dual
> >licenses of GPLv2 and GPLv3+ may be entered - formally - upstream and
> >into the linux kernel sources being maintained on git.kernel.org
>
> Umm - that was my point - though I did not make it explicitly.
>
> Either there is a policy change, and it is decided to allow such
> dual-licenced code in the repo, or your code does not get checked in,
> as it does not have a compatible licence.
Actually, it's more subtle than that. As I said earlier, we *do*
allow dual-licensed code in the repo, but it's on a per-file basis.
There is no way to designate that certain lines in a files has a
different copyright license than the lines in the file; I assume
people will understand why that's an accounting nightmare.
The more subtle thing to consider is that with dual-licensed code,
***anyone*** has the ability to strip one of the licenses from the
code in the course of making modification. So for example, suppose I
released e2fsck/recovery.c under GPLv2+. I would never do that,
because then someone might make improvements to the e2fsck/recovery.c
under GPLv3-only terms, and then strip the GPLv2 license from the file
and release it under GPLv3-only terms. That's a completely legal
thing to do; it may not be ethical, and it may not improve that
person's standing in the community, but it's completely legal. (It's
also identical to what the FSF has done when it has converted GPLv2+
projects to GPLv3-only projects, although it's a more acceptable when
the primary copyright owner of the file does it; what I'm calling out
here is that ***anyone*** can legally take GPLv2/v3 code and turn it
into GPLv2 or GPLv3 only code.)
The reason why I dislike someone taking GPLv2/v3 code and stripping
out the GPLv2 license is because it makes new versions of code which I
had originally written becoming available only under a GPLv3 license.
This would mean that in my example of e2fsck/recovery.c, those
enhacements would not be available for use in the Linux kernel as
fs/ext4/recovery.c. It's for the same reason why BSD folks get upset
when BSD code gets turned into GPLv2 code --- and the standard retort
to their being upset is "well, you shouldn't have released it under
the BSD license, then, since the BSD license will allow you to do
this". Applied to this GPLv2/GPLv3 incompatibility issue, and my
extreme dislike of the anti-Tivo clause in GPLv3, this explains why I
choose not to release my code under a GPLv2/GPLv3 dual-license or a
GPLv2+ license.
But there's a flip side to this, which is the same legal argument
***also*** allows a kernel maintainer to take a contribution which is
under a GPLv2/v3 or GPLv2+ license, and incorporate it into a
GPLv2-only file, and not bother to mark that it originally came from a
GPLv2+ or GPLv2/v3 contribution. The original contribution is still
licensed that way, and if you go through the mailing list archives,
you could find that contribution and extract that code and use it in
some other GPLv3 project. But we are under no obligation to mark that
a particular set of lines in a file originally came from a GPLv2/v3 or
GPLv2+ contribution.
But a very large number of senior Linux kernel developers (not just
Linus) have stated that we stand against the GPLv3 anti-Tivoization
clause, and so we intend to keep the Linux kernel sources under a
GPLv2-only license. That's not to say that certain drivers won't be
dual licensed, for specific reasons, but you shouldn't expect that
core kernel files will be GPLv3 compatible in the near future.
- Ted
On 05/18/2013 01:27:21 PM, luke.leighton wrote:
> On Sat, May 18, 2013 at 8:24 AM, Eric Appleman <[email protected]>
> wrote:
> > Would anyone be interested in forming such a pool?
>
> count me in.
>
> > Last I checked, I have 1 long-time poster of this list on board.
> Would
> > anyone else like to join? Ideally I'd like to get the LKML (which I
> have
> > CC'd) involved so that authors of critical Linux components be a
> part of
> > this. I'm not sure if my defconfig commits to Android kernel
> branches count
> > as contributions,
>
> even if you did not explicitly put "Copyright (C) {your name}" in
> them, you still retain copyright. depending on the country you are in
> you cannot even get rid of the copyright even if you say "i forever
> renounce irrevocably and without restriction or limitation all
> copyright and place this into the public domain signed me" - you have
> to actively assign the copyright to someone else.
>
> > so I'm not going to consider myself a Linux contributor
> > unless told otherwise.
>
> you wrote something that's copyrighted. therefore you're a copyright
> holder [therefore automatically any copyright violator must request
> your permission to have their GPLv2 license rights reinstated].
>
> my linux kernel modifications are small, too - they sort of winged
> their way by a slow process of migration into tmpfs by way of selinux
> xattrs. and there are likely some unattributed contributions that
> came from the xanadux.sf.net project originally (depending on whether
> they were picked up or not over time)
>
> but that makes no odds: i am still a copyright holder, ergo a
> contributor, ergo i'd like to be included in the pool please.
>
> > This pool would be used in the following manner:
> >
> > * Formally requesting source for binaries (means to request source
> > * Formally requesting removal of critical copyrighted code that
> Linux cannot
> > function without
> > * Informing interested parties with respect to refusals of the above
>
> it would also serve as a useful point of contact for criminal
> copyright violators wishing to have their license rights reinstated.
>
> also it would serve as a good starting point to be able to contact
> large numbers of people wishing to explicitly dual-license their code
> contributions to the linux kernel.
>
> actually, that's a good point. please can it be specifically noted,
> from this moment onwards, that all contributions that i have made to
> the linux kernel are dual-licensed under both the GPLv2 and also the
> GPLv3+ license?
I have a git repository that goes back to 0.0.1. The word "leighton"
(case insensitive) occurs in the full log exactly once, in a single
2004 commit that wasn't even done by you but was apparently inspired by
a patch you did.
> someone has to start somewhere on this. it doesn't matter if it takes
> 20 years for all GPLv2-exlusive contributions to be made obselete,
> deleted or replaced: a start has to be made.
You're aware that copyleft in general is declining, right?
"The GPL" was synonymous with copyleft. It was a terminal node in a
directed graph of license convertability, and the only thing
programmers had to know is whether or not some other license was
GPL-compatible. If it was: treat it as GPL. If it wasn't: ignore it.
But there's no "the GPL" anymore. Linux and Samba can't share code,
even though they implement two ends of the same protocol. And making
your project "GPLv2 or later" means you can't take code from _either_
source. These days the GPL largely serves to _prevent_ code re-use, and
people have responded to the percieved problems with "GPL-next"
initiatives where they fragment copyleft further with Affero variants,
by using creative commons on code, and so on. But copyleft only ever
worked as one big universal license, and now it doesn't.
In the absence of a universal receiver, most developers have switched
to universal donor licenses: MIT/BSD or even public domain. Yes,
"most": the most common license on Github is "no license specified",
and that's not just ignorance, that's napster-style civil disobedience
from a generation of coders who lump copyright in with software patents
and consider it all "too dumb to live". (You think GPL enforcement
suits are viewed any differently than DMCA takedown notices on youtube,
both coming from clueless old people?)
Now add in Android's official "no GPL in userspace" policy, which means
that if you preinstall GPL (or LGPL) software in your install image,
you can't use the Android trademark to describe your product. (Did I
mention that smartphones are replacing the PC? Mainframe, minicomputer,
microcomputer, smartphone:
http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=30s and that's why Android
matters; it can get preinstalled on that class of hardware. Linux has
been trying for 20 years and still has less than 2% marketshare on any
device an end-user interacts directly with.)
I'm sorry, but Richard Stallman _screwed_up_. GPLv3 suceeded where
Sun's CDDL failed: it split copyleft into incompatible warring factions
which are collectively shrinking in market share because none of them
are as useful a "The GPL" was.
I miss "the GPL". But it's gone. It seems to be being replaced by a
gradual shift to public domain code on the part of younger coders.
(Part of this may just be that proprietary software ran its course. The
ability to sell binary-only software was invented by the Apple vs
Franklin decision in 1983 extending copyright to binaries, and over the
next 20 years the market proved that just leads to abandonware and
monopoly exclusion. That's about when Microsoft peaked and started
stagnating, a dozen years ago. Making a killing selling shrinkwrapped
software isn't nearly as attractive as it used to be.*)
Advocating for GPLv2 to go away is sad, but understandable. Expecting
GPLv2 to be replaced by GPLv3 is just delusional.
Rob
* Except for terminal nodes like games where there can't be any lock-in
because users don't derive work product from the software. Users seem
to have developed a resistance to "you can hold my thesis for ransom
because I wrote it with your software and your gatekeeper program can
revoke my access to my own work", presumably because so many tools have
gone away over the years. Of course the lesson has to be learned all
over again with web services, and some things like photoshop are
grandfathered in. As always, reality is complicated...-
On Sun, 19 May 2013 11:57:15 +0100
"luke.leighton" <[email protected]> wrote:
> so. could someone please inform me what the procedure is: is it as
> simple as submitting a patch?
I think so(however I'm not a kernel maintainer),
I found that(however the patch is really old):
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=798b6b19d7a4b6e1ea5340ec8b3b92811e05b81b
So the idea would be to send a patch or series of patches to relicense
your code under the GPLv2+(GPLv2 or later).
Denis.
> actually, that's a good point. please can it be specifically noted,
> from this moment onwards, that all contributions that i have made to
> the linux kernel are dual-licensed under both the GPLv2 and also the
> GPLv3+ license?
Why not simply use "GPLv2 or later" ?
For instance in the copyright header.
Denis.
On Sat, 18 May 2013 03:24:31 -0400
Eric Appleman <[email protected]> wrote:
> Would anyone be interested in forming such a pool? I am willing to
> wait years for this to be resolved through certain organizations, but
> I believe we can do better.
yes, unfortunately I've only non-crucial code in mainline:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Denis+%27GNUtoo%27+Carikli
The drivers and hardware touched by my code are obsolete and will
probably not be used in newer products.
I've also some code not mentioned in the link above that made it into
mainline that I did for work. Since I don't own the copyright of it (my
employer does), it's not covered by this agreement.
>
> Last I checked, I have 1 long-time poster of this list on board.
> Would anyone else like to join?
yes, as long as it doesn't require spending too much time on it.
> Ideally I'd like to get the LKML
> (which I have CC'd) involved so that authors of critical Linux
> components be a part of this. I'm not sure if my defconfig commits to
> Android kernel branches count as contributions, so I'm not going to
> consider myself a Linux contributor unless told otherwise.
>
> This pool would be used in the following manner:
>
> * Formally requesting source for binaries (means to request source
ok
> * Formally requesting removal of critical copyrighted code that Linux
> cannot function without
I've no crucial code in mainline unfortunately.
> * Informing interested parties with respect to refusals of the above
ok
> The CTO of Anthrax's hosting server is very interested in terminating
> Chad Goodman's account. Bullet point #3 might come into effect here.
>
> If this is a bad idea, uses incorrect logic, or does not follow the
> conventions of GPL enforcement, feel free to shoot this idea down
> with utmost prejudice.
Seem good.
Denis.
On Wed, May 22, 2013 at 06:13:29PM +0200, Denis 'GNUtoo' Carikli wrote:
> On Sun, 19 May 2013 11:57:15 +0100 "luke.leighton" <[email protected]> wrote:
> > so. could someone please inform me what the procedure is: is it as
> > simple as submitting a patch?
> I think so(however I'm not a kernel maintainer),
> I found that(however the patch is really old):
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=798b6b19d7a4b6e1ea5340ec8b3b92811e05b81b
> So the idea would be to send a patch or series of patches to relicense
> your code under the GPLv2+(GPLv2 or later).
Only if you own the copyright on all of the lines of code of the file
in question.
- Ted