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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/01/watson.html

I’ve watched the game
show, Jeopardy!, regularly since its Trebek-hosted
relaunch on 1984-09-10. I even remember distinctly the Final Jeopardy
question that night as This date is the first day of the new
millennium. At the age of 11, I got the answer wrong, falling for
the incorrect What is 2000-01-01?, but I recalled this memory
eleven years ago during the
debates
regarding when the millennium turnover happened.

I had periods of life where I watched Jeopardy! only
rarely, but in recent years (as I’ve become more of a student of games
(in part, because of poker)), I’ve watched Jeopardy! almost
nightly over dinner with my wife. I’ve learned that I’m unlikely to
excel as a Jeopardy! player myself because (a) I read slow
and (b) my recall of facts, while reasonably strong, is not
instantaneous. I thus haven’t tried out for the show, but I’m
nevertheless a fan of strong players.

Jeopardy! isn’t my only spectator game. Right after
college, even though I’m a worse-than-mediocre chess player, I watched
with excitement
as Deep
Blue played and defeated Kasparov. Kasparov has disputed the
results and how much humans were actually involved, but even so, such
interference was minimal (between matches) and the demonstration still
showed computer algorithmic mastery of chess.

Of course, the core algorithms that Deep Blue used were well known and
often implemented. I learned α-β pruning in my undergraduate
AI course and it was clear that a sufficiently fast computer, given a
few strong heuristics, could beat most any full information game with a
reasonable branching factor. And, computers typically do these days.

I suppose I never really thought about the issues of Deep Blue being
released as Free Software. First, because I was not as involved with
Free Software then as I am now, and also, as near as anyone could tell,
Deep Blue’s software was probably not useful for anything other than
playing chess, and its primary power was in its ability to go very deep
(hence the name, I guess) in the search tree. In short, Deep Blue was
primarily a hardware, not a software, success story.

It was nevertheless, impressive, and last month, I saw the next
installment in this IBM story. I watched with interest
as IBM’s
Watson defeated two champion Jeopardy! players. Ken
Jennings, for one, even welcomed our new computer overlords.

Watson beating Jeopardy! is, frankly, a lot more
innovative than Deep Blue beating chess. Most don’t know this about me,
but I came very close to focusing my career on PhD work in Natural
Language Processing; I believe fundamentally it’s the area of AI most in
need of attention and research. Watson is a shining example of success
in modern NLP, and I actually believe some of the IBM hype about
how Watson’s
technology can be applied elsewhere, such as medical information
systems. Indeed, IBM
has announced
a deal with Columbia University Medical Center to adapt the system for
medical diagnostics. (Perhaps Watson’s next TV appearance will be
on House.)

This all sounds great to most people, but to me, my real concern is the
freedom of the software. We’ve shown in the software freedom community
that to advance software and improve it, sharing the software is
essential. Technology locked up in a vaulted cave doesn’t allow all the
great minds to collaborate. Just as we don’t lock up libraries so that
only the guilded overlords have access, nor should the best software
technology be restricted in proprietariness.

Indeed, Eric
Brown, at
his Linux
Foundation End User Linux Summit talk, told us that Watson relied
heavily on the publicly available software freedom codebase, such as
GNU/Linux, Hadoop, and other
FLOSS
components. They clearly couldn’t do their work without building upon the
work we shared with IBM, yet IBM apparently ignores its moral obligation to
reciprocate.

So, I just point-blank asked Brown why Watson is proprietary. Of
course, I long ago learned to never ask a confrontational question from
the crowd at a technical talk without knowing what the answer is likely to
be. Brown answered in the way I expected: We’re working with
Universities to provide a framework for their research. I followed
up asking
when he would actually release the sources and what license
would be. He dodged the question, and instead speculated about what
licenses IBM sometimes like to use when it does chose to release code;
he did not indicate if Watson’s sources will ever be released. In
short, the answer from IBM is clear: Watson’s general ideas
will be shared with academics, but the source code won’t be.

This point is precisely one of the reasons I didn’t pursue a career in
academic Computer Science. Since most jobs — including
professorships at Universities — for PhDs in Computer Science
require that any code written be kept proprietary, most
Computer Science researchers have convinced themselves that code doesn’t
matter; only publishing ideas do. This belief is so pervasive that I
knew something like this would be Brown’s response to my query. (I was
even so sure, I wrote almost this entire blog post before I asked the
question).

I’d easily agree that publishing papers is better than the technology
being only a trade secret. At least we can learn a little bit about the
work. But in all but the pure theoretical areas of Computer
Science, code is written to exemplify, test, and exercise the
ideas. Merely publishing papers and not the code is akin to a chemist
publishing final results but nothing about the methodologies or raw
data. Science, in such cases, is unverifiable and unreproducible. If
we accepted such in fields other than CS, we’d have accepted the idea
that cold
fusion was discovered in 1989.

I don’t think I’m going to convince IBM to release Watson’s sources as
Free Software. What I do hope is that perhaps this blog post convinces
a few more people that we just shouldn’t accept that Computer Science is
advanced by researchers who give us flashy demos and code-less
research papers. I, for one, welcome our computer overlords…but only
if I can study and modify their source code.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/01/watson.html

I’ve watched the game
show, Jeopardy!, regularly since its Trebek-hosted
relaunch on 1984-09-10. I even remember distinctly the Final Jeopardy
question that night as This date is the first day of the new
millennium. At the age of 11, I got the answer wrong, falling for
the incorrect What is 2000-01-01?, but I recalled this memory
eleven years ago during the
debates
regarding when the millennium turnover happened.

I had periods of life where I watched Jeopardy! only
rarely, but in recent years (as I’ve become more of a student of games
(in part, because of poker)), I’ve watched Jeopardy! almost
nightly over dinner with my wife. I’ve learned that I’m unlikely to
excel as a Jeopardy! player myself because (a) I read slow
and (b) my recall of facts, while reasonably strong, is not
instantaneous. I thus haven’t tried out for the show, but I’m
nevertheless a fan of strong players.

Jeopardy! isn’t my only spectator game. Right after
college, even though I’m a worse-than-mediocre chess player, I watched
with excitement
as Deep
Blue played and defeated Kasparov. Kasparov has disputed the
results and how much humans were actually involved, but even so, such
interference was minimal (between matches) and the demonstration still
showed computer algorithmic mastery of chess.

Of course, the core algorithms that Deep Blue used were well known and
often implemented. I learned α-β pruning in my undergraduate
AI course and it was clear that a sufficiently fast computer, given a
few strong heuristics, could beat most any full information game with a
reasonable branching factor. And, computers typically do these days.

I suppose I never really thought about the issues of Deep Blue being
released as Free Software. First, because I was not as involved with
Free Software then as I am now, and also, as near as anyone could tell,
Deep Blue’s software was probably not useful for anything other than
playing chess, and its primary power was in its ability to go very deep
(hence the name, I guess) in the search tree. In short, Deep Blue was
primarily a hardware, not a software, success story.

It was nevertheless, impressive, and last month, I saw the next
installment in this IBM story. I watched with interest
as IBM’s
Watson defeated two champion Jeopardy! players. Ken
Jennings, for one, even welcomed our new computer overlords.

Watson beating Jeopardy! is, frankly, a lot more
innovative than Deep Blue beating chess. Most don’t know this about me,
but I came very close to focusing my career on PhD work in Natural
Language Processing; I believe fundamentally it’s the area of AI most in
need of attention and research. Watson is a shining example of success
in modern NLP, and I actually believe some of the IBM hype about
how Watson’s
technology can be applied elsewhere, such as medical information
systems. Indeed, IBM
has announced
a deal with Columbia University Medical Center to adapt the system for
medical diagnostics. (Perhaps Watson’s next TV appearance will be
on House.)

This all sounds great to most people, but to me, my real concern is the
freedom of the software. We’ve shown in the software freedom community
that to advance software and improve it, sharing the software is
essential. Technology locked up in a vaulted cave doesn’t allow all the
great minds to collaborate. Just as we don’t lock up libraries so that
only the guilded overlords have access, nor should the best software
technology be restricted in proprietariness.

Indeed, Eric
Brown, at
his Linux
Foundation End User Linux Summit talk, told us that Watson relied
heavily on the publicly available software freedom codebase, such as
GNU/Linux, Hadoop, and other
FLOSS
components. They clearly couldn’t do their work without building upon the
work we shared with IBM, yet IBM apparently ignores its moral obligation to
reciprocate.

So, I just point-blank asked Brown why Watson is proprietary. Of
course, I long ago learned to never ask a confrontational question from
the crowd at a technical talk without knowing what the answer is likely to
be. Brown answered in the way I expected: We’re working with
Universities to provide a framework for their research. I followed
up asking
when he would actually release the sources and what license
would be. He dodged the question, and instead speculated about what
licenses IBM sometimes like to use when it does chose to release code;
he did not indicate if Watson’s sources will ever be released. In
short, the answer from IBM is clear: Watson’s general ideas
will be shared with academics, but the source code won’t be.

This point is precisely one of the reasons I didn’t pursue a career in
academic Computer Science. Since most jobs — including
professorships at Universities — for PhDs in Computer Science
require that any code written be kept proprietary, most
Computer Science researchers have convinced themselves that code doesn’t
matter; only publishing ideas do. This belief is so pervasive that I
knew something like this would be Brown’s response to my query. (I was
even so sure, I wrote almost this entire blog post before I asked the
question).

I’d easily agree that publishing papers is better than the technology
being only a trade secret. At least we can learn a little bit about the
work. But in all but the pure theoretical areas of Computer
Science, code is written to exemplify, test, and exercise the
ideas. Merely publishing papers and not the code is akin to a chemist
publishing final results but nothing about the methodologies or raw
data. Science, in such cases, is unverifiable and unreproducible. If
we accepted such in fields other than CS, we’d have accepted the idea
that cold
fusion was discovered in 1989.

I don’t think I’m going to convince IBM to release Watson’s sources as
Free Software. What I do hope is that perhaps this blog post convinces
a few more people that we just shouldn’t accept that Computer Science is
advanced by researchers who give us flashy demos and code-less
research papers. I, for one, welcome our computer overlords…but only
if I can study and modify their source code.