Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

[ I originally wrote this essay below centered around the term
“Open Core”. Despite that even say below that the terms is
somewhat
meaningless, I
later realized this term was so problematic that it should be
abandoned entirely, for use instead of the clearer term
“proprietary relicensing”. However, since this blog post was widely
linked to, I’ve nevertheless left the text as it originally was in
October 2009. ]

There has been some debate recently about so-called “Open
Core” business models. Throughout the history of Free Software,
companies have loved to come up with “innovative”
proprietary-like ways to use the FLOSS licensing structures.
Proprietary relicensing, a practice that I believe has proved itself to
have serious drawbacks, was probably the first of these, and now Open
Core is the next step in this direction. I believe the users embracing
these codebases may be ignoring a past they’re condemned to repeat.

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. Often, the model further uses the GPL to forbid anyone but
the copyright-holding company to make such proprietary add-on
applications (i.e., everyone else would have to GPL their applications).
In the current debate, some have proposed that a permissive license
structure can be used for the core instead.

Ultimately, “Open Core” is a glorified shareware situation.
As a user, you get some subset of functionality, and may even get the
four freedoms
with regard to that subset. But, when you want the “good
stuff”, you’ve got to take a proprietary license. And, this is
true whether the Core is GPL’d or permissively licensed. In both cases,
the final story is the same: take a proprietary license or be stuck with
cripple-ware.

This fact remains true whether the Open Core is under a copyleft
license or a permissive one. However, I must admit that a permissive
license is more intellectually honest to the users. When users
encounter a permissive license, they know what they are in for: they may
indeed encounter proprietary add-ons and improvements, either from the
original distributor or a third party. For example, Apple users sadly
know this all too well; Apple loves to build on a permissively licensed
core and proprietarize away. Yet, everyone knows what they’re getting
when they buy Apple’s locked down, unmodifiable, and
programmer-unfriendly products.

Meanwhile, in more typical “Open Core” scenarios, the use
of the GPL is actually somewhat insidious. I’ve written before
about how
the copyleft is a tool, not an end in itself. Like any tool, it can
be misused or abused. I think using the GPL as a tool for corporate
control over users, while legally permissible, is ignoring the spirit of
the license. It creates two classes of users: those precious few that
can proprietarize and subjugate others, and those that can’t.¹

This (ab)use of GPL has
led folks
like Matt Aslett to suggest that the permissive licensing solution
would serve this model better. While I’ve admitted such a change would
have some level of increased intellectually honesty, I don’t think it’s
the solution we should strive for to solve the problem. I think Aslett’s
completely right when he argues that GPL’d “Open Core”
became popular because it’s Venture Capitalists’ way of making peace
with freely licensed copyrights. However, heading to an Apple-like
permissive only structure only serves to make more Apple-like companies,
and that’s surely not good for software freedom either. In fact, the
problem is mostly orthogonal to licensing. It’s a community building
problem.

The first move we have to make is simply give up the idea that the best
technology companies are created by VC money. This may be true if your
goal is to create proprietary companies, but the best Free Software
companies are the small ones, 5-10 employees, that do consulting work
and license all their improvements back to a shared codebase. From
low-level technology like Linux and GCC to higher-level technology like
Joomla all show that this project structure yields popular and vibrant
codebases. The GPL was created to inspire business and community models
like these examples. The VC-controlled proprietary relicensing and
“Open Core” models are manipulations of the licensing
system. (For more on this part of my argument, I suggest my discussions
on
Episode
0x14 of the (defunct) Software Freedom Law Show.)

I realize that it’s challenging for a community to create these sort of
codebases. The best way to start, if you’re a small business, is to
find a codebase that gets you 40% or so toward your goal and start
contributing to the code with your own copyrights, licensed
under GPL. Having something that gets you somewhere will make it easier
to start your business on a consulting basis without VC, and allow you
to be part of one of these communities instead of trying to create an
“Open Core” community you can exploit with proprietary
licensing. Furthermore, the fact that you hold copyright alongside
others will give you a voice that must be heard in decision-making
processes.

Finally, if you find an otherwise useful
single-corporate-copyright-controlled GPL’d codebase from one of these
“Open Core” companies, there is something simple you can
do:

Fork! In essence, don’t give into pressure by these
companies to assign copyright to them. Get a group of community
developers together and maintain a fork of the codebase. Don’t be mean
about it, and use git or another DVCS to keep tracking branches of the
company’s releases. If enough key users do this and refuse to assign
copyright, the good version will eventually become community one rather
than the company-controlled one.

My colleague Carlo
Piana points
out a flaw in this plan, saying the ant cannot drive the
elephant. While I agree with Carlo generally, I also think that
software freedom has historically been a little bit about ants driving
elephants. These semi-proprietary business models are thriving on the
fundamental principle of a proprietary model: keep users from
cooperating to improve the code on which they all depend. It’s a
prisoner’s dilemma that makes each customer afraid to cooperate with the
other for fear that the other will yield to pressure not to cooperate.
As the fictional computer Joshua points out, this is a strange game.
The only winning move is not to play.

The software freedom world is more complex than it once was. Ten years
ago, we advocates could tell people to look for the GPL label and
know that the software would automatically be part of a
freedom-friendly, software sharing community. Not all GPL’d software is
created equal anymore, and while the right to fork remains firmly in
tact, the realities of whether such forks will survive, and whether the
entity controlling the canonical version can be trusted is another
question entirely. The new advice is: judge the freedom of your
codebase not only on its license, but also on the diversity of the
community that contributes to it.

¹I must
put a fine point here that the only way
companies can manipulate the GPL in this example is by
demanding full copyright assignment back to the corporate
entity. The GPL itself protects each individual contributor
from such treatment by other contributors, but when there is
only one contributor, those protections evaporate. I must
further note that for-profit corporate assignment differs
greatly from assignment to a non-profit, as non-profit
copyright assignment paperwork typically includes broad legal
assurances that the software will never be proprietarized, and
furthermore, the non-profit’s very corporate existence hinges
on engaging only in activity that promotes the public
good.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/11/denouncing-v-advocating.html

For the last decade, I’ve regularly seen complaints when we harder-core
software freedom advocates spend some time criticizing proprietary
software in addition to our normal work preserving, protecting and
promoting software freedom. While I think entire campaigns focused on
criticism are warranted in only extreme cases, I do believe that
denouncement of certain threatening proprietary technologies is a
necessary part of the software freedom movement, when done sparingly.

Denouncements are, of course, negative, and in general, negative
tactics are never as valuable as positive ones. Negative campaigns
alienate some people, and it’s always better to talk about the advantages
of software freedom than focus on the negative of proprietary
software.

The place where negative campaigns that denounce are simply necessary,
in my view, is when the practice either (a) will somehow completely
impeded the creation of FLOSS or (b) has become, or is becoming,
widespread among people who are otherwise supportive of software
freedom.

I can think quickly of two historical examples of the first type: UCITA
and DRM. UCITA was a State/Commonwealth-level law in the USA that was
proposed to make local laws more consistent regarding software
distribution. Because the implications were so bad
for software freedom (details of which are beyond scope of this post but
can be learned at the link), and because it was so unlikely that we
could get the UCITA drafts changed, it was necessary to publicly denounce
the law and hope that it didn’t pass. (Fortunately, it only ever passed
in my home state of Maryland and in Virginia. I am still, probably
pointlessly, careful never to distribute software when I visit my
hometown. 🙂

DRM, for its part, posed an even greater threat to software freedom
because its widespread adoption would require proprietarization of all
software that touched any television, movie, music, or book media. There
was also a concerted widespread pro-DRM campaign from USA corporations.
Therefore, grassroots campaigns denouncing DRM are extremely necessary
even despite that they are primarily negative in operation.

The second common need for denouncement when use of a proprietary
software package has become acceptable in the software freedom community.
The most common examples are usually specific proprietary software
programs that have become (or seem about to become) “all but
standard” part of the toolset for Free Software developers and
advocates.

Historically, this category included Java, and that’s why there were
anti-Java campaigns in the Free Software community that ran concurrently
with Free Software Java development efforts. The need for the former is
now gone, of course, because the latter efforts were so successful and we
have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was
historically necessary, but is also now moot because of the advent and
widespread popularity of Mercurial, Git, and Bazaar.

Today, there are still a few proprietary programs that quickly rose to
ranks of “must install on my GNU/Linux system” for all but the
hardest-core Free Software advocates. The key examples are Adobe Flash
and Skype. Indeed, much to my chagrin, nearly all of my co-workers at
SFLC insist on using Adobe Flash, and nearly every Free Software developer
I meet at conferences uses it too. And, despite excellent VoIP technology
available as Free Software, Skype has sadly become widely used in our
community as well.

When a proprietary system becomes as pervasive in our community as
these have (or looks like it might), it’s absolutely time for
denouncement. It’s often very easy to forget that we’re relying more and
more heavily on proprietary software. When a proprietary system
effectively becomes the “default” for use on software freedom
systems, it means fewer people will be inspired to write a
replacement. (BTW, contribute to Gnash!) It means that Free Software
advocates will, in direct contradiction of their primary mission, start to
advocate that users install that proprietary software, because it
seems to make the FaiF platform “more useful”.

Hopefully, by now, most of us in the software freedom community agree
that proprietary software is a long term trap that we want to avoid.
However, in the short term, there is always some new shiny thing.
Something that appeals to our prurient desire for software that
“does something cool”. Something that just seems so
convenient that we convince ourselves we cannot live without it, so we
install it. Over time, short term becomes the long term, and suddenly we
have gaping holes in the Free Software infrastructure that only the very
few notice because the rest just install the proprietary thing. For
example, how many of us bother to install Linux Libre,
even long enough to at least know which of our hardware
components needs proprietary software? Even I have to admit I don’t do
this, and probably should.

An old adage of software development is that software is always better
if the developers of it actually have to use the thing from day to day.
If we agree that our goal is ultimately convincing everyone to run only
Free Software (and for that Free Software to fit their needs), then we
have to trailblaze by avoiding running proprietary software ourselves. If
you do run proprietary software, I hope you won’t celebrate the fact or
encourage others to do so. Skype is particularly insidious here, because
it’s a community application. Encouraging people to call you on Skype is
the same as emailing someone a Microsoft Word document: it’s encouraging
someone to install a proprietary application just to work with you.

Finally, I think the only answer to the FLOSS community
celebrating the arrival of some new proprietary program for
GNU/Linux is to denounce it, as a counterbalance to the fervor that such
an announcement causes. My podcast co-host Karen
often calls me the canary in the software coalmine because I am
usually the first to notice something that is bad for the advancement of
software freedom before anyone else does. In playing this role, I often
end up denouncing a few things here and there, although I can still count
on my two hands the times I’ve done so. I agree that advocacy should be
the norm, but the occasional denouncement is also a necessary part of the
picture.

(Note: this blog is part of an ongoing public discussion of a software
program that is not too popular yet, but was heralded widely as a win for
Free Software in the USA. I didn’t mention it by name mainly because I
don’t want to give it more press than it’s already gotten, as it is one of
this programs that is becoming a standard GNU/Linux user
application (at least in the USA), but hasn’t yet risen to the level of
ubiquity of the other examples I give above. Here’s to hoping that it
doesn’t.)