Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.

Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/pea/

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html

I certainly deserve some of the blame, and for that I certainly
apologize: the phrase “Open Core” has apparently become a
slur word, used by those who wish to discredit the position of someone
else without presenting facts. I’ve done my best when using the term to
also give facts that backed up the claim, but even so, I finally
abandoned the term back in November 2010, and I hope you will too.

The story, from my point of view, began seventeen months ago, when I
felt
that “Open
Core” was a definable term and that behavior was a
dangerous practice. I gave it the clear definition that I felt
reflected problematic behavior, as I wrote at the time:

Like most buzzwords, Open Core has no real agreed-upon meaning. I’m using
it to describe a business model whereby some middleware-ish system is
released by a single, for-profit entity copyright holder, who requires
copyright-assigned changes back to the company, and that company sells
proprietary add-ons and applications that use the framework.

Later — shortly after
I pointed
out Mark Shuttleworth’s fascination with and leanings towards this
practice — I realized that it
was better
to use the preexisting, tried-and-true term for the practice:
“proprietary relicensing”. I’ve
been pretty consistent in avoiding the term “Open Core”
since then. I
called
on Shuttleworth to adopt the FSF’s recommendations to show Canonical,
Ltd. isn’t seeking proprietary relicensing and left the whole thing
at that. (Shuttleworth, of course, has refused to even respond, BTW.)

Sadly, it was too late: I’d help create a monster. A few weeks later,
Alexandre Oliva
(whose positions on the issue of
proprietary software inside the kernel named Linux I definitely
agree with) took it a step too far
and called the kernel named
Linux an “Open Core” project. Obviously, Linux
developers don’t and can’t engage in proprietary relicensing; some just
engage in a “look the other way” mentality with regard to
proprietary components inside Linux. At the time,
I said
that the term “Open Core” was clearly just too confusing to
analyze a real-world licensing situation.

So, I just stopped calling things “Open Core”. My concerns
currently are regarding the practice of collecting copyright assignments
to copyleft software and engaging in proprietary relicensing activity,
and I’ve focused on advocating against that specific practice. That’s
what I’ve criticized Canonical, Ltd. for doing — both with their
existing copyright assignment policies and with their effort to extend
those policies community-wide with the manipulatively named
“Project Harmony”.

Shuttleworth, for his part, is now making use the slur phrase I’d
inadvertently help create. Specifically,
a
few days ago, Shuttleworth accused Fedora of being an “Open
Core” product.

I’ve often said that Fedora is primarily a Red Hat corporate
project (and
it’s among
the reasons that I run Debian rather than Fedora). However, since
“Open Core” clearly still has no agreed-upon meaning, when I
read what Shuttleworth said, I considered the question of whether his
claim had any merit (using the “Open Core” definition I used
myself before I abandoned the term). Put simply, I asked myself the
question: Does Red Hat engaged in “proprietary relicensing of copyleft software
with mandatory copyright assignment or non-copyleft CLA“ with Fedora?.

Fact is, despite having serious reservations about how the RHEL
business model works, I have no evidence to show that Red
Hat requires copyright assignment or a mandatory non-copyleft
CLA on copyleft projects on any
products other than
Cygwin. So, if Shuttleworth had said: Cygwin is Red
Hat’s Open Core product, I would still encourage him that we should all
now drop the term “Open Core”, but I would also agree with him that
Cygwin is a proprietary-relicensed product and that we should urge Red Hat
to abandon that practice. (Update: It’s also
been noted by Fontana on identi.ca
(although the statement was subsequently deleted by the user)
that some JBoss projects require permissive CLAs but licenses back out
under LGPL, so that would be another example.)

But does Fedora require contributors to assign copyright or do
non-copyleft licensing? I can’t find the evidence, but there are some
confusing facts. Fedora has
a Contributor Licensing Agreement (CLA), which, in §1(D),
clearly allows contributors to chose their own license. If the
contributor accepts all the defaults on the existing Fedora CLA, the
contributor gives a permissive license to the contribution (even for
copyleft projects). Fortunately, though, the author can easily copyleft
a work under the agreement, and it is still accepted by Fedora.
(Contrast this
with Canonical,
Ltd.’s mandatory copyright assignment form, which explicitly
demands Canonical, Ltd.’s power for proprietary relicensing.)

While Fedora’s current CLA does push people toward permissive licensing
of copylefted works,
the new
draft of the Fedora CLA is much clearer on this point (in §2).
In other words, the proposed replacement closes this bug. It thus seems
to me Red Hat is looking to make things better, while Canonical,
Ltd. hoodwinks us and is manufacturing consent in Project
“Harmony” around a proprietary copyright-grab by for-profit
corporations. When I line up the two trajectories, Red Hat’s slowly
getting better, and Canonical, Ltd. is quickly getting worse. Thus,
Shuttleworth, sitting in his black pot, clearly has no right say that
the slightly brown kettle sitting next to him is black, too.

It could be that Shuttleworth is actually thinking of the RHEL business
model itself, which is actually quite different than proprietary
relicensing. I do have strong, negative opinions about the RHEL
business model; I have long called it the if you like copyleft, your
money is no good here business model. It’s a GPL-compliant business
model merely because the GPL is silent on whether or not you must keep
someone as your customer. Red Hat tells RHEL customers that if they
chose to engage in their rights under GPL, then their support contract
will be canceled. I’ve often pointed out (although this may be the
first time publicly on the Internet) that Red Hat found a bright line of
GPL compliance, walked right up to it, and were the first to stake out a
business model right on the line. (I’ve been told, though, that Cygnus
experimented with this business model before being acquired by Red Hat.)
This practice is, frankly, barely legitimate.

Ironically, RMS and I used to say that Canonical, Ltd.’s new business
model of interest — proprietary relicensing (once trailblazed by
MySQL AB) — was also barely legitimate. In one literal
sense, that’s still true: it’s legitimate in the sense that it doesn’t
violate GPL. In the sense of software freedom morality, I think
proprietary relicensing harms the Free Software community too much, and
that it was therefore a mistake to ever tolerate it.

As for RHEL’s business model, I’ve never liked it, but I’m still unsure
(even ten years later since its inception) about its software freedom
morality. It doesn’t seem as harmful as proprietary relicensing. In
proprietary licensing, those mistreated under the model are the small
business and individual developers who are pressured to give up their
copyleft rights lest their patches be rejected or rewritten. The small
entities are left to chose between maintaining a fork or giving over
proprietary corporate control of the codebase. In RHEL’s business
model, by contrast, the mistreated entities are large corporations that
are forced to choose between exercising their GPL rights and losing
access to the expensive RHEL support. It seems to me that the RHEL
model is not immoral, but I definitely find it unfriendly and
inappropriate, since it says: if you exercise software freedom, you
can’t be our customer.

However, when we analyze these models that occupy the zone between
license legitimacy and software freedom morality, I think I’ve learned
from the mistake of using slur phrases like “Open Core”.
From my point of view, most of these “edge” business models
have ill effects on software freedom and community building, and we have
to examine their nuances mindfully and gage carefully the level of harm
caused. Sometimes, over time, that harm shows itself to be unbearable
(as with proprietary relicensing). We must stand against such models
and meanwhile continue to question the rest with precise analysis.