Discussion:
Is the GPL being used to punish the wrong deveopers
SonWon
2013-05-27 12:47:44 UTC
Permalink
What is the purpose of open free software?

Imposing narrow interpretations on the usage of open free software will
kill this movement one day. The goal should be to prevent open source code
from being used to make money from your hard work, and to give you credit.
The GPL was developed to prevent open source code from being stolen and
resold for commercial gain. If your code is being used for financial gain
then this is a violation of free open software concepts. If someone
improves the code and shares with the community then great, if not, no
worries. I don't feel any loss if they don't share their improvements. I
do however feel a loss when they take code that was open and free and turn
it into a money making machine. This destroys the concept of open free
software. Nit picking every little detail of the GPL over who violated
what is just plain going to destroy this community one day. We can see it
happening right now, the way we nitpick over who didn't or did shared when
the real focus should be on those who are involved with making money off of
your hard work. So called developers are using your code to solicit
donations. Valid developers that freely share their code can't receive
credit because some other comes along and steals their work. Then the
thief uses the stolen code, claims he developed it first, just to solicit
more donations. Real developers that want to share their code are driven
underground. Stealing your code isn't about one man, one developer, the
issues here are much larger. This is about the future of open source
software. The real thief's are protected and making money off your open
source code. If this continues this will one day destroy open source.
This is all wrong.
Ralph Corderoy
2013-05-27 17:42:11 UTC
Permalink
Hi SonWon,
Post by SonWon
Imposing narrow interpretations on the usage of open free software
will kill this movement one day.
Precise interpretations of free software licences haven't killed the
`movement' after many years. They would not be much use if imposed in an
imprecise manner.
Post by SonWon
The goal should be to prevent open source code from being used to make
money from your hard work, and to give you credit.
I disagree.
Post by SonWon
The GPL was developed to prevent open source code from being stolen
and resold for commercial gain.
It's been a long time since I read about the history of free software
but I'm pretty sure that wasn't the primary intent.
Post by SonWon
If your code is being used for financial gain then this is a violation
of free open software concepts.
No it's not. Software released under GNU GPL can directly be used by
others for financial gain.
Post by SonWon
If someone improves the code and shares with the community then great,
if not, no worries.
Correct. Private, non-distributed improvements may remain just that.
Post by SonWon
I don't feel any loss if they don't share their improvements. I do
however feel a loss when they take code that was open and free and
turn it into a money making machine.
Cygnus turned GPL'd software into a money-making machine. As have Red
Hat. With them the code remained open.
Post by SonWon
Nit picking every little detail of the GPL over who violated what is
just plain going to destroy this community one day.
You wouldn't be referring to my examination of Chad's actions as to
whether he met 3(b) when distributing, would you? That's not
nit-picking. It's fundamental. Where a violation starts is where it
needs to be fixed.
Post by SonWon
We can see it happening right now, the way we nitpick over who didn't
or did shared when the real focus should be on those who are involved
with making money off of your hard work.
Hmm, this is ringing familiar bells.
Post by SonWon
So called developers are using your code to solicit donations. Valid
developers that freely share their code can't receive credit because
some other comes along and steals their work. Then the thief uses the
stolen code, claims he developed it first, just to solicit more
donations. Real developers that want to share their code are driven
underground.
If only the creator had published the source code, or provided a written
offer to it, when distributing. Then there would be a mark in the sand
to clearly refute the `thief's claims. Instead, you seem to suggest
that having one's copyright violated allows one to do the same to many
others. It doesn't. Someone nicking my wallet doesn't make me immune
from arrest if I become a pickpocket in retaliation.
Post by SonWon
Stealing your code isn't about one man, one developer, the issues here
are much larger. This is about the future of open source software.
The real thief's are protected and making money off your open source
code. If this continues this will one day destroy open source. This
is all wrong.
IMHO you are not going to switch the focus to this. It will remain on
Chad's attempted loophole to the GPL v2. You're wasting your time and
the many subscribers. Anyone that takes GPL v2'd source, modifies it,
and distributes the binary, and therefore their modified source if
they're complying, should have read the licence and understand money may
be made by others from it.

Cheers, Ralph.
Eric Appleman
2013-05-28 05:13:30 UTC
Permalink
Post by Ralph Corderoy
Hi SonWon,
Post by SonWon
Imposing narrow interpretations on the usage of open free software
will kill this movement one day.
Precise interpretations of free software licences haven't killed the
`movement' after many years. They would not be much use if imposed in an
imprecise manner.
Post by SonWon
The goal should be to prevent open source code from being used to make
money from your hard work, and to give you credit.
I disagree.
Post by SonWon
The GPL was developed to prevent open source code from being stolen
and resold for commercial gain.
It's been a long time since I read about the history of free software
but I'm pretty sure that wasn't the primary intent.
Post by SonWon
If your code is being used for financial gain then this is a violation
of free open software concepts.
No it's not. Software released under GNU GPL can directly be used by
others for financial gain.
Post by SonWon
If someone improves the code and shares with the community then great,
if not, no worries.
Correct. Private, non-distributed improvements may remain just that.
Post by SonWon
I don't feel any loss if they don't share their improvements. I do
however feel a loss when they take code that was open and free and
turn it into a money making machine.
Cygnus turned GPL'd software into a money-making machine. As have Red
Hat. With them the code remained open.
Post by SonWon
Nit picking every little detail of the GPL over who violated what is
just plain going to destroy this community one day.
You wouldn't be referring to my examination of Chad's actions as to
whether he met 3(b) when distributing, would you? That's not
nit-picking. It's fundamental. Where a violation starts is where it
needs to be fixed.
Post by SonWon
We can see it happening right now, the way we nitpick over who didn't
or did shared when the real focus should be on those who are involved
with making money off of your hard work.
Hmm, this is ringing familiar bells.
Post by SonWon
So called developers are using your code to solicit donations. Valid
developers that freely share their code can't receive credit because
some other comes along and steals their work. Then the thief uses the
stolen code, claims he developed it first, just to solicit more
donations. Real developers that want to share their code are driven
underground.
If only the creator had published the source code, or provided a written
offer to it, when distributing. Then there would be a mark in the sand
to clearly refute the `thief's claims. Instead, you seem to suggest
that having one's copyright violated allows one to do the same to many
others. It doesn't. Someone nicking my wallet doesn't make me immune
from arrest if I become a pickpocket in retaliation.
Post by SonWon
Stealing your code isn't about one man, one developer, the issues here
are much larger. This is about the future of open source software.
The real thief's are protected and making money off your open source
code. If this continues this will one day destroy open source. This
is all wrong.
IMHO you are not going to switch the focus to this. It will remain on
Chad's attempted loophole to the GPL v2. You're wasting your time and
the many subscribers. Anyone that takes GPL v2'd source, modifies it,
and distributes the binary, and therefore their modified source if
they're complying, should have read the licence and understand money may
be made by others from it.
Cheers, Ralph.
Here's an interesting conundrum:

According to Chad's Google+ account, his newest kernels contain a
/sbin/readme with instructions on how to receive source.

From: https://plus.google.com/105084384299106728552/posts/3Vu4JQETSM3

"Any kernels I release to the public in the future will also have full
current and correct source code. Any "public" kernel released by me to
the general public will have information in /sbin/readme on how to
acquire source (since per the GPL I only need to provide source to the
programs users - once the program is installed, they can read how to
obtain source)."

**once the program is installed**

That strikes me as a huge problem. We previously discussed including
/proc/config.gz in the kernel to convey a defconfig, but what about
source request instructions? I've never heard of it being kosher to
include instructions inside of a binary rather than included along with it.

Even if I were to obtain one of these newer files, my Verizon Galaxy S3
(SCH-I535) is not guaranteed to boot Sprint (SPH-L710) kernels. Most of
the files Chad posts in development threads are meant for Sprint and I
don't recall ever having a Verizon kernel, although I likely snagged at
least one along the way. I can't even be sure his public test kernels
with weird names include the readme, just the fancy-labelled more
official ones I suppose. If I want an HTC kernel source for a binary I
downloaded, I'm out of luck since I wouldn't have the necessary hardware
to access the readme.

Therefore, according to Chad, simply downloading an Anthrax binary does
not afford me the means to obtain source. Unless the instructions are
visible in the zip, I have to either boot the kernel (which may fail and
temporarily brick my phone) or somehow magically disassemble it to
access that readme file.

This arrangement seems to shrink the pool of theoretical people Chad
would willingly provide source to. Here's how I see it.

* You need to be someone unknown to Chad. You can still access his
message board by linking your Facebook account for manual approval. I
assume that anyone from this list would be denied.

* You need to become a poster in good standing, have a number of useful
posts, and wait good long while to be manually verified.

* You need to have the proper phone for each file you download. Assuming
the instructions are baking into the kernel binary and not visible in
the zip, if you want a Sprint GS3 source, you need a Sprint GS3. If you
want an HTC EVO source, you need an HTC EVO.

All of the above is completely unreasonable and serve only to prevent
requests, instill loyalty, and force people to prove they have a certain
phone.

One final remark, Chris "flastnoles" Bunch, a poster on this list and
Anthrax member, was going to request and provide source for a number of
kernels before he inexplicably backed out and claimed he was hacked.
Somehow these plans were discovered and tied to Chris. If someone hacked
him, I find that unacceptable and reprehensible. If not hacked, I kindly
ask that he reconsider, follow through on his intentions, and not give
into intimidation from anyone who would wish to penalize him for a
source request.

- Eric Appleman
Neil Brown
2013-05-28 11:28:44 UTC
Permalink
I've never heard of it being kosher to include instructions inside
of a binary rather than included along with it.
Although not strictly a legal interpretation, I would probably look to
take a pragmatic view here.

If someone were to sell a router, and were to include the offer as
part of the web GUI (e.g. in the equivalent of an "about" screen)
instead of as a piece of paper in the box, I would have thought this
would be more than acceptable: the aim of provision of the licence is
one of raising awareness.

Similarly, with Android devices, most I have seen have satisfied the
requirements about inclusion of a copy of the licence text by
including this within the device interface; I would have thought that
putting the offer in the same place would be suitable.

I'd be very interested in other views on this.

(I'd also ask very nicely if people would mind snipping quotations to
which they are responding, so that only the relevant part is included,
to make reading things a little easier?)


Neil
--
Neil Brown

***@neilzone.co.uk | http://neilzone.co.uk
Ralph Corderoy
2013-05-28 12:41:07 UTC
Permalink
Hi Neil,
Post by Neil Brown
If someone were to sell a router, and were to include the offer as
part of the web GUI (e.g. in the equivalent of an "about" screen)
instead of as a piece of paper in the box, I would have thought this
would be more than acceptable: the aim of provision of the licence is
one of raising awareness.
I think I disagree. It's a long time ago now, but when I persuaded
Amstrad that they had to supply the Linux kernel's source used on their
E3 videophone they added the written offer into the GUI of the phone, as
you suggest. The problem was, IIRC, that this part of the GUI was only
accessible once the device had `phoned home' as part of its
registration. IOW, dialling a premium line and passing on my phone
number. That doesn't seem acceptable to me.

Also, as a programmer, what if I learn of a Linux kernel binary for
device A that's similar to device B that I have but not compatible
enough to run the binary? Perhaps I've less RAM but want to support
similar peripherals. I want to take up the written offer buried in it
in order to help with B's development. It may be that I can disassemble
the binary enough, e.g. the written offer is visible in the initial RAM
disk, but it could be more entwined somewhere in compressed form. I
shouldn't have to disassemble to get the offer of the source that means
I don't have to disassemble. :-)

If the source is readily available and locatable then I agree it's less
important but where hoops are being put in place to jump through, such
as Amstrad's `send a cheque for £25 for a CD', then a pucker written
offer accompanying the binary should be more insisted upon IMHO. (The
CD didn't contain matching source BTW; Amstrad claimed to be too busy
to sort it out, but perhaps they didn't have it.)

Cheers, Ralph.
Oliver Schinagl
2013-05-29 06:47:59 UTC
Permalink
Post by Ralph Corderoy
Hi Neil,
Post by Neil Brown
If someone were to sell a router, and were to include the offer as
part of the web GUI (e.g. in the equivalent of an "about" screen)
instead of as a piece of paper in the box, I would have thought this
would be more than acceptable: the aim of provision of the licence is
one of raising awareness.
I think I disagree. It's a long time ago now, but when I persuaded
Amstrad that they had to supply the Linux kernel's source used on their
E3 videophone they added the written offer into the GUI of the phone, as
you suggest. The problem was, IIRC, that this part of the GUI was only
accessible once the device had `phoned home' as part of its
registration. IOW, dialling a premium line and passing on my phone
number. That doesn't seem acceptable to me.
I think I agree with you here Ralph. Isn't it about 'freedom of the
user', that the user can edit/modify etc the source.
Post by Ralph Corderoy
Also, as a programmer, what if I learn of a Linux kernel binary for
device A that's similar to device B that I have but not compatible
enough to run the binary? Perhaps I've less RAM but want to support
similar peripherals. I want to take up the written offer buried in it
in order to help with B's development. It may be that I can disassemble
the binary enough, e.g. the written offer is visible in the initial RAM
disk, but it could be more entwined somewhere in compressed form. I
shouldn't have to disassemble to get the offer of the source that means
I don't have to disassemble. :-)
Sorta exactly my point. What if the app crashes and I can't read it.

This brings up the point of the /proc/config.gz situation. However I
should note (while I have not confirmed) there appearantly ARE tools to
extract said config from a NON running kernel. So does not apply.


So ... how does this of course legally work, how inconvenient for the
users it is.
Post by Ralph Corderoy
Cheers, Ralph.
Oliver

P.S. This sounds like a really nasty way to make it as hard as possible
for the user. And again, while it could possibly not be a violation (I
would think it is), it is definitely against the spirit of the GPL.
Henrik Nordström
2013-06-05 20:37:48 UTC
Permalink
Post by Neil Brown
Similarly, with Android devices, most I have seen have satisfied the
requirements about inclusion of a copy of the licence text by
including this within the device interface; I would have thought that
putting the offer in the same place would be suitable.
I sare this view.

Regards
Henrik

Ralph Corderoy
2013-05-28 11:46:15 UTC
Permalink
Hi Eric,
Your interesting points aside, please don't quote all the lines of the
email you're replying to only to `bottom post'. Some of us use email
clients that don't collapse the quotes down just because they appeared
in an earlier email so it's 72 lines of noise (three screenfuls ;-) to
get past and generally considered bad netiquette, especially by
old-timers like you'll probably find on this list.

Cheers, Ralph.
Eric Appleman
2013-05-28 15:26:53 UTC
Permalink
"/sbin/readme" is not part of the kernel, no? or does his kernel fake
that file at runtime?
Unknowable, unless somebody from the site wants to chime in.

If the kernel is distributed as part of a rom, I could understand the
readme being visible inside of the zip, but the "offer" seems to be for
kernel releases.

A typical Android kernel zip includes the binary zImage, the modules, dd
for flashing the kernel, an optional kernel configuration binary, and
the zip's manifest. Not much else and a text readme file would not be
unheard of.
If someone were to sell a router, and were to include the offer as
part of the web GUI (e.g. in the equivalent of an "about" screen)
instead of as a piece of paper in the box, I would have thought this
would be more than acceptable: the aim of provision of the licence is
one of raising awareness.
Similarly, with Android devices, most I have seen have satisfied the
requirements about inclusion of a copy of the licence text by
including this within the device interface; I would have thought that
putting the offer in the same place would be suitable.
Android presents its licenses through "License Information" in the
Settings GUI. I could also understand a router doing the same thing.

Chad's readme is either a modification of a GPLv2 COPYING template or a
separate document specifically dealing with source acquisition. I think
the router analogy fails here because GUI displays of license are
typically a part of the device's out-of-box experience. I don't need to
riskily install dd-wrt on my router to view its license or source
acquisition methods from a file or GUI, such information is readily
available. Similarly, I wouldn't expect an Android kernel to bury an
offer deep within a binary and risk a soft-bricking to access. It might
be passable to have the offer being a part of a kernel ramdisk since
that can be accessed without booting, but unpacking a boot.img is not
something your average kernel flasher understands how to do.

Honestly, what good is an offer if its existence cannot be confirmed
readily, is apparently not retroactive, and its terms are not meant for
public scrutiny?

- Eric
Oliver Schinagl
2013-05-29 06:55:54 UTC
Permalink
Post by Eric Appleman
"/sbin/readme" is not part of the kernel, no? or does his kernel fake
that file at runtime?
Unknowable, unless somebody from the site wants to chime in.
If the kernel is distributed as part of a rom, I could understand the
readme being visible inside of the zip, but the "offer" seems to be for
kernel releases.
That's an interesting concept, and since I'm no legal expert nor am I a
lawyer, I only voice my opinion.

It is highly unlikely (possible it's a kernel module that exports it as
virtual file) that it is part of the kernel. Actually, the readme is
part of the ROM, or rather disk-image, which isn't really an offer with
the kernel.

Also, wasn't the whole idea that you could audit a kernel, from its
source, before installing it? Wasn't that part of the five freedoms? So
thinking about it, I can imagine this actually as being a violation.

Oliver
Angus Gratton
2013-05-29 23:36:57 UTC
Permalink
Post by Oliver Schinagl
Post by Eric Appleman
If the kernel is distributed as part of a rom, I could understand the
readme being visible inside of the zip, but the "offer" seems to be for
kernel releases.
That's an interesting concept, and since I'm no legal expert nor am
I a lawyer, I only voice my opinion.
It is highly unlikely (possible it's a kernel module that exports it
as virtual file) that it is part of the kernel. Actually, the readme
is part of the ROM, or rather disk-image, which isn't really an
offer with the kernel.
FWIW, I think Android relies on something similar with it's
About->Legal option. All the legal notices including kernel details
are there, accessible that way on the device itself and also in a
plaintext file on the filesystem image.

As far as I know some vendors will also ship printed legal notices in
the box, but I believe not all of them do this.

IANAL Google's legal minds seem to think this is OK, and in my
personal opinion it's also compliant with the spirit of the GPL.

At any rate AFAIK if a third party doesn't like the notice
distribution method they can always repost the kernel with the
information from the original offer notice reformatted in a more
accessible way, under the terms of GPLv2 3(c). The original offer
information remains legitimate & binding on the redistributed package
provided the kernel binary itself remains unmodified.

- Angus
Oliver Schinagl
2013-05-30 09:14:06 UTC
Permalink
Post by Angus Gratton
FWIW, I think Android relies on something similar with it's
About->Legal option. All the legal notices including kernel details
are there, accessible that way on the device itself and also in a
plaintext file on the filesystem image.
As far as I know some vendors will also ship printed legal notices in
the box, but I believe not all of them do this.
To be fair, in google's case, they have the license online I'd think
and, more importantly, have the source. So having the license inside is
just a bonus, a good one at that. I'll admit that might just be a little
too specific.
Daniel Berlin
2013-05-31 04:05:24 UTC
Permalink
On Thu, May 30, 2013 at 2:14 AM, Oliver Schinagl
Post by Angus Gratton
FWIW, I think Android relies on something similar with it's
About->Legal option. All the legal notices including kernel details
are there, accessible that way on the device itself and also in a
plaintext file on the filesystem image.
As far as I know some vendors will also ship printed legal notices in
the box, but I believe not all of them do this.
To be fair, in google's case, they have the license online I'd think and,
more importantly, have the source. So having the license inside is just a
bonus, a good one at that. I'll admit that might just be a little too
specific.
Google is also not the one shipping most of the devices :)
Daniel Berlin
2013-05-31 04:04:55 UTC
Permalink
Post by Angus Gratton
Post by Oliver Schinagl
Post by Eric Appleman
If the kernel is distributed as part of a rom, I could understand the
readme being visible inside of the zip, but the "offer" seems to be for
kernel releases.
That's an interesting concept, and since I'm no legal expert nor am
I a lawyer, I only voice my opinion.
It is highly unlikely (possible it's a kernel module that exports it
as virtual file) that it is part of the kernel. Actually, the readme
is part of the ROM, or rather disk-image, which isn't really an
offer with the kernel.
FWIW, I think Android relies on something similar with it's
About->Legal option. All the legal notices including kernel details
are there, accessible that way on the device itself and also in a
plaintext file on the filesystem image.
It's actually an HTML file, in /etc/NOTICE.html.gz
Post by Angus Gratton
As far as I know some vendors will also ship printed legal notices in
the box, but I believe not all of them do this.
I hope not, there were 100+ pages of notices at one point.
I don't remember any license in android that required specific notice
in printed documentation rather than in documentation or other
materials given to the user.
It's entirely possible certain vendors have added code that requires
printed notice, however.
Post by Angus Gratton
IANAL Google's legal minds seem to think this is OK, and in my
personal opinion it's also compliant with the spirit of the GPL.
I lost track of the the question, but I believe it is "does the offer
for source have to be embedded in the kernel", I can state I have
never heard of anyone taking the opinion that it must be directly
embedded in the kernel, or the kernel rom, or anything of the sort.
Only that it must be accompanying it in a way that the user always
gets it, and the user can find it.
Even a strict reading of the GPL makes this clear: " Accompany it with
a written offer"
Not "embed in it a written offer", but "accompany with".
Post by Angus Gratton
At any rate AFAIK if a third party doesn't like the notice
distribution method they can always repost the kernel with the
information from the original offer notice reformatted in a more
accessible way, under the terms of GPLv2 3(c).
False. This is a compliance mechanism is that is an alternative to
the other two, and only available to noncommercial redistributions, if
they came with a written offer. That is, if you are a *noncommercial*
redistribution, rather than make your own written offer, or accompany
it with source, simply reproducing an existing written offer by
another party would be sufficient to comply.
Post by Angus Gratton
information remains legitimate & binding on the redistributed package
provided the kernel binary itself remains unmodified.
- Angus
Angus Gratton
2013-05-31 04:41:50 UTC
Permalink
Hi Daniel,

My post actually makes more sense if you read this part of Oliver's
original post, that I wrong-headedly snipped from my reply. Sorry
Post by Oliver Schinagl
Also, wasn't the whole idea that you could audit a kernel, from its
source, before installing it? Wasn't that part of the five freedoms?
So thinking about it, I can imagine this actually as being a
violation.
Post by Angus Gratton
IANAL Google's legal minds seem to think this is OK, and in my
personal opinion it's also compliant with the spirit of the GPL.
I lost track of the the question, but I believe it is "does the offer
for source have to be embedded in the kernel", I can state I have
never heard of anyone taking the opinion that it must be directly
embedded in the kernel, or the kernel rom, or anything of the sort.
Only that it must be accompanying it in a way that the user always
gets it, and the user can find it.
Even a strict reading of the GPL makes this clear: " Accompany it with
a written offer"
Not "embed in it a written offer", but "accompany with".
I agree with you. I was more pointing out ways in which "accompany
with" can include "accompanied in a way that may require you to use
the software in order to read it", for example the case of buying an
Android phone where the notices are stored on the same internal flash
memory as the kernel. To read the GPL notice for the kernel you have
to run it (or dissect the phone and dump the flash memory somehow, I
guess.)
Post by Oliver Schinagl
Post by Angus Gratton
At any rate AFAIK if a third party doesn't like the notice
distribution method they can always repost the kernel with the
information from the original offer notice reformatted in a more
accessible way, under the terms of GPLv2 3(c).
False. This is a compliance mechanism is that is an alternative to
the other two, and only available to noncommercial redistributions, if
they came with a written offer. That is, if you are a *noncommercial*
redistribution, rather than make your own written offer, or accompany
it with source, simply reproducing an existing written offer by
another party would be sufficient to comply.
Sorry, I obviously wrote this email while half-awake. In this example
I meant to move from Android back to the example of Chad Goodman and
his "/sbin/readme" offer for source.

My point being that if some third party wants to then they can avail
themselves of 3(c) and redistribute a kernel compiled by Chad Goodman,
along with the information[1] from "/sbin/readme" put into some other
form they think is more reader-friendly (provided they aren't
modifying or selling the kernel he provided them, as you point out.)

- Angus

[1] The specific wording of 3(c) is "information you received" so
presumably you're allowed to reformat it if you don't change the
information content.
Daniel Berlin
2013-05-31 07:04:33 UTC
Permalink
Post by Angus Gratton
Hi Daniel,
My post actually makes more sense if you read this part of Oliver's
original post, that I wrong-headedly snipped from my reply. Sorry
No problemo :)
Post by Angus Gratton
Post by Oliver Schinagl
Also, wasn't the whole idea that you could audit a kernel, from its
source, before installing it? Wasn't that part of the five freedoms?
So thinking about it, I can imagine this actually as being a
violation.
Post by Angus Gratton
IANAL Google's legal minds seem to think this is OK, and in my
personal opinion it's also compliant with the spirit of the GPL.
I lost track of the the question, but I believe it is "does the offer
for source have to be embedded in the kernel", I can state I have
never heard of anyone taking the opinion that it must be directly
embedded in the kernel, or the kernel rom, or anything of the sort.
Only that it must be accompanying it in a way that the user always
gets it, and the user can find it.
Even a strict reading of the GPL makes this clear: " Accompany it with
a written offer"
Not "embed in it a written offer", but "accompany with".
I agree with you. I was more pointing out ways in which "accompany
with" can include "accompanied in a way that may require you to use
the software in order to read it", for example the case of buying an
Android phone where the notices are stored on the same internal flash
memory as the kernel.
Yes, and this applies equally well to almost anything using the kernel.

For example, without specialized software, I can't read the notices
directly from an ubuntu iso prior to installing the thing (much less
from a pre-made ext4 image, which do exist for VM's, etc). Much like
Ubuntu, we provide source ahead of time if you wanted to look at it,
but ...
Post by Angus Gratton
To read the GPL notice for the kernel you have
to run it (or dissect the phone and dump the flash memory somehow, I
guess.)
This is what led to the interactive program requirement for the GPL.
So that in cases where it was sane to do so, you would know it was GPL'd.

Since the kernel is non-interactive (for all intents and purposes,
unless you make a habit of dropping into kdb), it is not required to
display such notices on its own. Thus, the notices have to go
somewhere. Since people often end up with phones that have no
manuals, the sanest place is on the phone itseelf.

Realistically, at least in the US, you are unlikely to get a judge to
ever care about things like the above. Unless it is *very* explicitly
in the license, with no room for ambiguity, judges are likely to treat
it like any other contract, and come up with a sane interpretation.
They will also require good faith and reasonableness.
Thus, if you ever tried to argue "I can't read the notices without
running the software", the first thing that would happen is that the
judge would say "did you ask them for a copy of the notices?".
Vladimir Pantelic
2013-05-31 08:03:42 UTC
Permalink
Angus Gratton wrote:> On Wed, May 29, 2013 at 08:55:54AM +0200, Oliver
Post by Angus Gratton
Post by Oliver Schinagl
Post by Eric Appleman
If the kernel is distributed as part of a rom, I could understand the
readme being visible inside of the zip, but the "offer" seems to be for
kernel releases.
That's an interesting concept, and since I'm no legal expert nor am
I a lawyer, I only voice my opinion.
It is highly unlikely (possible it's a kernel module that exports it
as virtual file) that it is part of the kernel. Actually, the readme
is part of the ROM, or rather disk-image, which isn't really an
offer with the kernel.
FWIW, I think Android relies on something similar with it's
About->Legal option. All the legal notices including kernel details
are there, accessible that way on the device itself and also in a
plaintext file on the filesystem image.
yes, but Google also ships a written GPL offer in paper form, all the
Nexus devices I have seen so far have that.
Post by Angus Gratton
As far as I know some vendors will also ship printed legal notices in
the box, but I believe not all of them do this.
IANAL Google's legal minds seem to think this is OK, and in my
personal opinion it's also compliant with the spirit of the GPL.
About->Legal has more than just the GPL, there are also all the other
licenses that demand mention, but not a written offer for source code.
Daniel Berlin
2013-05-31 20:18:29 UTC
Permalink
Post by Vladimir Pantelic
Angus Gratton wrote:> On Wed, May 29, 2013 at 08:55:54AM +0200, Oliver
Post by Angus Gratton
Post by Oliver Schinagl
Post by Eric Appleman
If the kernel is distributed as part of a rom, I could understand the
readme being visible inside of the zip, but the "offer" seems to be for
kernel releases.
That's an interesting concept, and since I'm no legal expert nor am
I a lawyer, I only voice my opinion.
It is highly unlikely (possible it's a kernel module that exports it
as virtual file) that it is part of the kernel. Actually, the readme
is part of the ROM, or rather disk-image, which isn't really an
offer with the kernel.
FWIW, I think Android relies on something similar with it's
About->Legal option. All the legal notices including kernel details
are there, accessible that way on the device itself and also in a
plaintext file on the filesystem image.
yes, but Google also ships a written GPL offer in paper form, all the Nexus
devices I have seen so far have that.
This may actually go away, these sleeves are more expensive than one
might think.
Post by Vladimir Pantelic
Post by Angus Gratton
As far as I know some vendors will also ship printed legal notices in
the box, but I believe not all of them do this.
IANAL Google's legal minds seem to think this is OK, and in my
personal opinion it's also compliant with the spirit of the GPL.
About->Legal has more than just the GPL, there are also all the other
licenses that demand mention, but not a written offer for source code.
This is only because this is common to all android devices, and thus,
people would mistakenly thing we provide source for HTC or Samsung.
There should be another page that says you can grab source from AOSP,
though i can't remember the exact menu sequence :)
Neil Brown
2013-05-27 17:48:26 UTC
Permalink
Post by SonWon
This is all wrong.
I have a feeling that others may not share your views, or your interpretation of the Free philosophy, in the context of the situation here!


Neil

-----
***@neilzone.co.uk | http://neilzone.co.uk
Manu Abraham
2013-05-27 18:30:54 UTC
Permalink
Post by SonWon
What is the purpose of open free software?
The original purpose of open free software is that recipients/users of
the software may modify, fix the software to their own tastes, without
a lockin to happen. As simple as that.

I do remember a RMS tale of a printer getting jammed, where he wanted
to fix the issue but was unable to do so, due to lockin/source not available.
he story seemed to go on that GPL evolved out of that scenario.

Well, this holds good for almost all people.

Regards,
Manu
luke.leighton
2013-05-28 04:50:49 UTC
Permalink
Post by Manu Abraham
Post by SonWon
What is the purpose of open free software?
The original purpose of open free software is that recipients/users of
the software may modify, fix the software to their own tastes, without
a lockin to happen. As simple as that.
lock-in: i.e. abuse of power. if you don't have the right to modify
the source code, then you are forced to reverse-engineer back to the
metal.

i don't know if you've ever done reverse-engineering, sonwon: it's a
fucking awful waste of good engineer's time. i *have* done
reverse-engineering, sonwon. in 1996 i was forced into a situation of
reverse-engineering NT domains encryption (which resulted in a
lines-of-code per day metric of ONE THIRD - 0.33 - i.e. it took me
NINETY days to create 30 critical lines of code). i was forced into a
situation to reverse-engineer the NT Domains networking protocols: it
took 3 years of my life, and with help from five or six volunteers we
managed to create about 150,000 lines of code implementing full NT 4.0
Domains interoperability.

i was also forced in 2004 to do reverse-engineering of wince HTC
smartphones, to get linux onto them. one of those phones took *only*
six to eight weeks to get everything but suspend/resume working, but
the others took months to get only partial success.

then, also, in 2010 i was forced to do *more* reverse-engineering,
this time of a GPL-violating 2.6.24 ARM-based netbook. i had
persuaded 20 people to buy the device but incredibly embarrasingly the
supplier did not honour the GPL, because *their* suppliers had
violated the GPL.

so i was forced to spend three very intense weeks reverse-engineering
a 2.6.24 kernel back onto this device.

the point is, sonwon, that i personally have the intelligence to
compensate for the abuse of power that *not* providing source code
forces onto me, and even i get pretty pissed off because i could be
doing other things with my life and with my time.

now imagine asking the average programmer to do that kind of thing.
what do you imagine they're going to do? they're going to walk away,
aren't they?

btw: during that linux 2.6.4 kernel reverse-engineering, we
discovered that the linux kernel had had a number of "security"
lock-in attempts added. as they were software-only, the
reverse-engineered kernel of course didn't have to check their
"security" measures so we were free to run anything that we wanted.

now.

another question.

why are we discussing this on a list that is dedicated to the
discussion of GPL legal issues?

l.
Loading...