Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/08/gpl-enforcement.html

In one of my favorite
movies, Office
Space, Tom Smykowski (one of the fired employees) has a
magic-eight-ball-style novelty product idea:
a “Jump
to Conclusions” mat. Sometimes, I watch discussions in the
software freedom community and think that, as a community, we’re all
jumping around on one of these mats.

I find that people are most likely to do this when something seems
novel and exciting. I don’t really blame anyone for doing it; I do it
myself when I have discovered an exciting thing that’s new to me, even
if it’s well known by others. But, often, this new thing is actually
rather mundane, and it’s better to check in with the existing knowledge
about the idea before “jumping” to any conclusions. In
other words, the best square on the mat for us to land on is the one
that reads: Think again!

Meanwhile, as some who follow
my microblog know, I’ve
been on a mission in recent months to establish just how common and
mundane GPL violations are. Since 21 August 2009, I’ve been finding one
new GPL violating company per day (on average) and I am still on target
to find one per day for 365 days straight. When I tell this to people
who are new to GPL enforcement, they are surprised and impressed.
However, when I tell people who have done GPL enforcement themselves,
they usually say some version of: Am I supposed to be impressed by
that? Couldn’t a monkey do that? Fact is, the latter are a little
bit right: there are so many GPL violations that I might easily be able
to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I
believe firmly they should be addressed, and I continue to dedicate much
of my life to resolve them. However, finding yet another GPL violation
isn’t a huge and earth-shaking discovery. Indeed, it’s what I was doing
today to kill time while drinking my Sunday morning coffee.

I don’t mean to imply that I don’t appreciate greatly when folks find
new GPL violations. I think finding and reporting GPL violations is a
very valuable service, and I wouldn’t spend so much time finding them
myself if I didn’t value the work highly. But, the work is more akin to
closing annoying bugs than it is to launching a paradigm-shifting FLOSS
project. Closing bugs is an essential part of FLOSS development, but no
one blogs about every single bug they close (although maybe we do
microblog them ;).

Having this weekend witnessed another community tempest about a
potential GPL violation, I decided to share a few guidelines that I
encourage everyone to follow when finding a GPL violation. (In other
words, what follows are a some basic guidelines for reporting
violations; other such guides are also available
at the
FSF’s site
and the
gpl-violations.org site (which is now defunct, since gpl-violations.org is
no longer active.)

• Assume the violation is an oversight or an accident by the violator
  until you have clear evidence that tells you differently. I’d say
  that 98% of the violations I’ve ever worked on since 1998 have been
  unintentional and due primarily to negligence, not malice.

• Don’t go public first. Back around late 1999, when I
  found my first GPL violation from scratch, I wanted to post it to every
  mailing list I could find and shame that company that failed to respect
  and cooperate with the software freedom community. I’m glad that I
  didn’t do that, because I’ve since seen similar actions destroy the
  lines of communication with violators, and make resolution tougher.
  Indeed, I believe that if the Cisco/Linksys violations had not been a
  center of public ridicule in 2003 when I (then at the FSF) was in the
  midst of negotiating with them for compliance, we would not have ended
  up with such
  a long
  saga
  to resolution.

• Do contact the copyright holders, or their designated
  enforcement agents. Since
  the GPL
  is a copyright license, if the violator fails to comply on their own,
  only the copyright holder (typically) has the power to enforce the
  license⁰.
  Here’s a list of contact addresses that I know for reporting various
  violations (if you know more such addresses, please let me know and I’ll
  add them here):

  • Linux, BusyBox, Samba, Mercurial, uClibc: <[email protected]&gt
    (this address is primarily answered by me currently)
  • FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc,
    binutils): <[email protected]>
  • iptables, netfilter, mtd, initrd and
    msdosfs: <[email protected]>
    (note: gpl-violations.org is no longer active so this address might no
    longer work)
  • XviD: <[email protected]>

  If the GPL’d project you’ve found a violation on isn’t on the list above,
  just find email addresses of people with commit access to the repository
  for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS
  files. It’s better not to post the violation to a public discussion list
  for the project, as that’s just “going public”.

• Never treat a “community violator” the same way as a
  for-profit violator. I believe there is a fundamental difference
  between someone who makes a profit during the act of infringement than
  someone who merely seeks to contribute as a volunteer and screws
  something up. There isn’t a perfect line between the two — it’s a
  spectrum. However, those who don’t make any money from their
  infringement are probably just confused community members who
  misunderstood the GPL and deserve pure education and non-aggressive
  enforcement. Those who make money from the infringement deserve some
  friendly education too, of course, but ultimately they are making a
  profit by ignoring the rights of their users. I think these situations
  are fundamentally different, and deserve different tactics.

• Once you’ve reported a violation, please be patient with those of us
  doing enforcement. There are always hundreds of GPL violations that
  need action, and there are very few of us engaged in regular and active
  enforcement. Also, most of us try to get compliance not just on the
  copyrights we represent, but all GPL’d software. (This behooves both
  the software freedom community and the violator, as the former wants to
  see broad compliance, and the latter doesn’t want to deal with each
  copyright holder individually). Thus, it takes much time and effort to
  do each enforcement action. So, when you report a new violation, it
  might take some time for the situation to resolve.

• Do try your best to request source from the violator
  on your own. While making the violation public doesn’t help, inquiring
  privately does often help. If you have received distribution of a
  binary that you think is GPL’d or LGPL’d (or used a network service that
  you think is AGPL’d), do write to the violator (typically best to use the
  technical support channels) and ask for the complete and corresponding
  source code. Be as polite and friendly as possible, and always assume
  it is their intention to comply until you have specific evidence that
  they don’t intend to do so.

• Share as much good information with the violator as you can to
  encourage their compliance. My colleagues and
  I wrote A
  Practical Guide to GPL Compliance for just this purpose.

We need a careful balance regarding GPL enforcement. Remember that the
primary goal of the GPL is encourage more software freedom in the world.
For many violators, the first experience the violator has with FLOSS is
an enforcement action. We therefore must ensure that enforcement action
is reasonable and friendly. I view every GPL violator as a potential
FLOSS contributor, and try my best to open every enforcement action with
that attitude. I am human and thus sometimes become more frustrated
with uncooperative violators than I should be. However, striving for
kindness with violators only helps give a great image to the software
freedom community.

⁰In
some situations, there are a few possibilities for users that
exist if the copyright holder is unable or unwilling to enforce
the GPL. We’ve actually recently seen an interesting
successful enforcement by a user. I plan to blog in detail
about this soon.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/08/gpl-enforcement.html

In one of my favorite
movies, Office
Space, Tom Smykowski (one of the fired employees) has a
magic-eight-ball-style novelty product idea:
a “Jump
to Conclusions” mat. Sometimes, I watch discussions in the
software freedom community and think that, as a community, we’re all
jumping around on one of these mats.

I find that people are most likely to do this when something seems
novel and exciting. I don’t really blame anyone for doing it; I do it
myself when I have discovered an exciting thing that’s new to me, even
if it’s well known by others. But, often, this new thing is actually
rather mundane, and it’s better to check in with the existing knowledge
about the idea before “jumping” to any conclusions. In
other words, the best square on the mat for us to land on is the one
that reads: Think again!

Meanwhile, as some who follow
my microblog know, I’ve
been on a mission in recent months to establish just how common and
mundane GPL violations are. Since 21 August 2009, I’ve been finding one
new GPL violating company per day (on average) and I am still on target
to find one per day for 365 days straight. When I tell this to people
who are new to GPL enforcement, they are surprised and impressed.
However, when I tell people who have done GPL enforcement themselves,
they usually say some version of: Am I supposed to be impressed by
that? Couldn’t a monkey do that? Fact is, the latter are a little
bit right: there are so many GPL violations that I might easily be able
to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I
believe firmly they should be addressed, and I continue to dedicate much
of my life to resolve them. However, finding yet another GPL violation
isn’t a huge and earth-shaking discovery. Indeed, it’s what I was doing
today to kill time while drinking my Sunday morning coffee.

I don’t mean to imply that I don’t appreciate greatly when folks find
new GPL violations. I think finding and reporting GPL violations is a
very valuable service, and I wouldn’t spend so much time finding them
myself if I didn’t value the work highly. But, the work is more akin to
closing annoying bugs than it is to launching a paradigm-shifting FLOSS
project. Closing bugs is an essential part of FLOSS development, but no
one blogs about every single bug they close (although maybe we do
microblog them ;).

Having this weekend witnessed another community tempest about a
potential GPL violation, I decided to share a few guidelines that I
encourage everyone to follow when finding a GPL violation. (In other
words, what follows are a some basic guidelines for reporting
violations; other such guides are also available
at the
FSF’s site
and the
gpl-violations.org site (which is now defunct, since gpl-violations.org is
no longer active.)

• Assume the violation is an oversight or an accident by the violator
  until you have clear evidence that tells you differently. I’d say
  that 98% of the violations I’ve ever worked on since 1998 have been
  unintentional and due primarily to negligence, not malice.

• Don’t go public first. Back around late 1999, when I
  found my first GPL violation from scratch, I wanted to post it to every
  mailing list I could find and shame that company that failed to respect
  and cooperate with the software freedom community. I’m glad that I
  didn’t do that, because I’ve since seen similar actions destroy the
  lines of communication with violators, and make resolution tougher.
  Indeed, I believe that if the Cisco/Linksys violations had not been a
  center of public ridicule in 2003 when I (then at the FSF) was in the
  midst of negotiating with them for compliance, we would not have ended
  up with such
  a long
  saga
  to resolution.

• Do contact the copyright holders, or their designated
  enforcement agents. Since
  the GPL
  is a copyright license, if the violator fails to comply on their own,
  only the copyright holder (typically) has the power to enforce the
  license⁰.
  Here’s a list of contact addresses that I know for reporting various
  violations (if you know more such addresses, please let me know and I’ll
  add them here):

  • Linux, BusyBox, Samba, Mercurial, uClibc: <[email protected]&gt
    (this address is primarily answered by me currently)
  • FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc,
    binutils): <[email protected]>
  • iptables, netfilter, mtd, initrd and
    msdosfs: <[email protected]>
    (note: gpl-violations.org is no longer active so this address might no
    longer work)
  • XviD: <[email protected]>

  If the GPL’d project you’ve found a violation on isn’t on the list above,
  just find email addresses of people with commit access to the repository
  for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS
  files. It’s better not to post the violation to a public discussion list
  for the project, as that’s just “going public”.

• Never treat a “community violator” the same way as a
  for-profit violator. I believe there is a fundamental difference
  between someone who makes a profit during the act of infringement than
  someone who merely seeks to contribute as a volunteer and screws
  something up. There isn’t a perfect line between the two — it’s a
  spectrum. However, those who don’t make any money from their
  infringement are probably just confused community members who
  misunderstood the GPL and deserve pure education and non-aggressive
  enforcement. Those who make money from the infringement deserve some
  friendly education too, of course, but ultimately they are making a
  profit by ignoring the rights of their users. I think these situations
  are fundamentally different, and deserve different tactics.

• Once you’ve reported a violation, please be patient with those of us
  doing enforcement. There are always hundreds of GPL violations that
  need action, and there are very few of us engaged in regular and active
  enforcement. Also, most of us try to get compliance not just on the
  copyrights we represent, but all GPL’d software. (This behooves both
  the software freedom community and the violator, as the former wants to
  see broad compliance, and the latter doesn’t want to deal with each
  copyright holder individually). Thus, it takes much time and effort to
  do each enforcement action. So, when you report a new violation, it
  might take some time for the situation to resolve.

• Do try your best to request source from the violator
  on your own. While making the violation public doesn’t help, inquiring
  privately does often help. If you have received distribution of a
  binary that you think is GPL’d or LGPL’d (or used a network service that
  you think is AGPL’d), do write to the violator (typically best to use the
  technical support channels) and ask for the complete and corresponding
  source code. Be as polite and friendly as possible, and always assume
  it is their intention to comply until you have specific evidence that
  they don’t intend to do so.

• Share as much good information with the violator as you can to
  encourage their compliance. My colleagues and
  I wrote A
  Practical Guide to GPL Compliance for just this purpose.

We need a careful balance regarding GPL enforcement. Remember that the
primary goal of the GPL is encourage more software freedom in the world.
For many violators, the first experience the violator has with FLOSS is
an enforcement action. We therefore must ensure that enforcement action
is reasonable and friendly. I view every GPL violator as a potential
FLOSS contributor, and try my best to open every enforcement action with
that attitude. I am human and thus sometimes become more frustrated
with uncooperative violators than I should be. However, striving for
kindness with violators only helps give a great image to the software
freedom community.

⁰In
some situations, there are a few possibilities for users that
exist if the copyright holder is unable or unwilling to enforce
the GPL. We’ve actually recently seen an interesting
successful enforcement by a user. I plan to blog in detail
about this soon.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/08/gpl-enforcement.html

In one of my favorite
movies, Office
Space, Tom Smykowski (one of the fired employees) has a
magic-eight-ball-style novelty product idea:
a “Jump
to Conclusions” mat. Sometimes, I watch discussions in the
software freedom community and think that, as a community, we’re all
jumping around on one of these mats.

I find that people are most likely to do this when something seems
novel and exciting. I don’t really blame anyone for doing it; I do it
myself when I have discovered an exciting thing that’s new to me, even
if it’s well known by others. But, often, this new thing is actually
rather mundane, and it’s better to check in with the existing knowledge
about the idea before “jumping” to any conclusions. In
other words, the best square on the mat for us to land on is the one
that reads: Think again!

Meanwhile, as some who follow
my microblog know, I’ve
been on a mission in recent months to establish just how common and
mundane GPL violations are. Since 21 August 2009, I’ve been finding one
new GPL violating company per day (on average) and I am still on target
to find one per day for 365 days straight. When I tell this to people
who are new to GPL enforcement, they are surprised and impressed.
However, when I tell people who have done GPL enforcement themselves,
they usually say some version of: Am I supposed to be impressed by
that? Couldn’t a monkey do that? Fact is, the latter are a little
bit right: there are so many GPL violations that I might easily be able
to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I
believe firmly they should be addressed, and I continue to dedicate much
of my life to resolve them. However, finding yet another GPL violation
isn’t a huge and earth-shaking discovery. Indeed, it’s what I was doing
today to kill time while drinking my Sunday morning coffee.

I don’t mean to imply that I don’t appreciate greatly when folks find
new GPL violations. I think finding and reporting GPL violations is a
very valuable service, and I wouldn’t spend so much time finding them
myself if I didn’t value the work highly. But, the work is more akin to
closing annoying bugs than it is to launching a paradigm-shifting FLOSS
project. Closing bugs is an essential part of FLOSS development, but no
one blogs about every single bug they close (although maybe we do
microblog them ;).

Having this weekend witnessed another community tempest about a
potential GPL violation, I decided to share a few guidelines that I
encourage everyone to follow when finding a GPL violation. (In other
words, what follows are a some basic guidelines for reporting
violations; other such guides are also available
at the
FSF’s site
and the
gpl-violations.org site (which is now defunct, since gpl-violations.org is
no longer active.)

• Assume the violation is an oversight or an accident by the violator
  until you have clear evidence that tells you differently. I’d say
  that 98% of the violations I’ve ever worked on since 1998 have been
  unintentional and due primarily to negligence, not malice.

• Don’t go public first. Back around late 1999, when I
  found my first GPL violation from scratch, I wanted to post it to every
  mailing list I could find and shame that company that failed to respect
  and cooperate with the software freedom community. I’m glad that I
  didn’t do that, because I’ve since seen similar actions destroy the
  lines of communication with violators, and make resolution tougher.
  Indeed, I believe that if the Cisco/Linksys violations had not been a
  center of public ridicule in 2003 when I (then at the FSF) was in the
  midst of negotiating with them for compliance, we would not have ended
  up with such
  a long
  saga
  to resolution.

• Do contact the copyright holders, or their designated
  enforcement agents. Since
  the GPL
  is a copyright license, if the violator fails to comply on their own,
  only the copyright holder (typically) has the power to enforce the
  license⁰.
  Here’s a list of contact addresses that I know for reporting various
  violations (if you know more such addresses, please let me know and I’ll
  add them here):

  • Linux, BusyBox, Samba, Mercurial, uClibc: <[email protected]&gt
    (this address is primarily answered by me currently)
  • FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc,
    binutils): <[email protected]>
  • iptables, netfilter, mtd, initrd and
    msdosfs: <[email protected]>
    (note: gpl-violations.org is no longer active so this address might no
    longer work)
  • XviD: <[email protected]>

  If the GPL’d project you’ve found a violation on isn’t on the list above,
  just find email addresses of people with commit access to the repository
  for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS
  files. It’s better not to post the violation to a public discussion list
  for the project, as that’s just “going public”.

• Never treat a “community violator” the same way as a
  for-profit violator. I believe there is a fundamental difference
  between someone who makes a profit during the act of infringement than
  someone who merely seeks to contribute as a volunteer and screws
  something up. There isn’t a perfect line between the two — it’s a
  spectrum. However, those who don’t make any money from their
  infringement are probably just confused community members who
  misunderstood the GPL and deserve pure education and non-aggressive
  enforcement. Those who make money from the infringement deserve some
  friendly education too, of course, but ultimately they are making a
  profit by ignoring the rights of their users. I think these situations
  are fundamentally different, and deserve different tactics.

• Once you’ve reported a violation, please be patient with those of us
  doing enforcement. There are always hundreds of GPL violations that
  need action, and there are very few of us engaged in regular and active
  enforcement. Also, most of us try to get compliance not just on the
  copyrights we represent, but all GPL’d software. (This behooves both
  the software freedom community and the violator, as the former wants to
  see broad compliance, and the latter doesn’t want to deal with each
  copyright holder individually). Thus, it takes much time and effort to
  do each enforcement action. So, when you report a new violation, it
  might take some time for the situation to resolve.

• Do try your best to request source from the violator
  on your own. While making the violation public doesn’t help, inquiring
  privately does often help. If you have received distribution of a
  binary that you think is GPL’d or LGPL’d (or used a network service that
  you think is AGPL’d), do write to the violator (typically best to use the
  technical support channels) and ask for the complete and corresponding
  source code. Be as polite and friendly as possible, and always assume
  it is their intention to comply until you have specific evidence that
  they don’t intend to do so.

• Share as much good information with the violator as you can to
  encourage their compliance. My colleagues and
  I wrote A
  Practical Guide to GPL Compliance for just this purpose.

We need a careful balance regarding GPL enforcement. Remember that the
primary goal of the GPL is encourage more software freedom in the world.
For many violators, the first experience the violator has with FLOSS is
an enforcement action. We therefore must ensure that enforcement action
is reasonable and friendly. I view every GPL violator as a potential
FLOSS contributor, and try my best to open every enforcement action with
that attitude. I am human and thus sometimes become more frustrated
with uncooperative violators than I should be. However, striving for
kindness with violators only helps give a great image to the software
freedom community.

⁰In
some situations, there are a few possibilities for users that
exist if the copyright holder is unable or unwilling to enforce
the GPL. We’ve actually recently seen an interesting
successful enforcement by a user. I plan to blog in detail
about this soon.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/08/gpl-enforcement.html

In one of my favorite
movies, Office
Space, Tom Smykowski (one of the fired employees) has a
magic-eight-ball-style novelty product idea:
a “Jump
to Conclusions” mat. Sometimes, I watch discussions in the
software freedom community and think that, as a community, we’re all
jumping around on one of these mats.

I find that people are most likely to do this when something seems
novel and exciting. I don’t really blame anyone for doing it; I do it
myself when I have discovered an exciting thing that’s new to me, even
if it’s well known by others. But, often, this new thing is actually
rather mundane, and it’s better to check in with the existing knowledge
about the idea before “jumping” to any conclusions. In
other words, the best square on the mat for us to land on is the one
that reads: Think again!

Meanwhile, as some who follow
my microblog know, I’ve
been on a mission in recent months to establish just how common and
mundane GPL violations are. Since 21 August 2009, I’ve been finding one
new GPL violating company per day (on average) and I am still on target
to find one per day for 365 days straight. When I tell this to people
who are new to GPL enforcement, they are surprised and impressed.
However, when I tell people who have done GPL enforcement themselves,
they usually say some version of: Am I supposed to be impressed by
that? Couldn’t a monkey do that? Fact is, the latter are a little
bit right: there are so many GPL violations that I might easily be able
to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I
believe firmly they should be addressed, and I continue to dedicate much
of my life to resolve them. However, finding yet another GPL violation
isn’t a huge and earth-shaking discovery. Indeed, it’s what I was doing
today to kill time while drinking my Sunday morning coffee.

I don’t mean to imply that I don’t appreciate greatly when folks find
new GPL violations. I think finding and reporting GPL violations is a
very valuable service, and I wouldn’t spend so much time finding them
myself if I didn’t value the work highly. But, the work is more akin to
closing annoying bugs than it is to launching a paradigm-shifting FLOSS
project. Closing bugs is an essential part of FLOSS development, but no
one blogs about every single bug they close (although maybe we do
microblog them ;).

Having this weekend witnessed another community tempest about a
potential GPL violation, I decided to share a few guidelines that I
encourage everyone to follow when finding a GPL violation. (In other
words, what follows are a some basic guidelines for reporting
violations; other such guides are also available
at the
FSF’s site
and the
gpl-violations.org site (which is now defunct, since gpl-violations.org is
no longer active.)

• Assume the violation is an oversight or an accident by the violator
  until you have clear evidence that tells you differently. I’d say
  that 98% of the violations I’ve ever worked on since 1998 have been
  unintentional and due primarily to negligence, not malice.

• Don’t go public first. Back around late 1999, when I
  found my first GPL violation from scratch, I wanted to post it to every
  mailing list I could find and shame that company that failed to respect
  and cooperate with the software freedom community. I’m glad that I
  didn’t do that, because I’ve since seen similar actions destroy the
  lines of communication with violators, and make resolution tougher.
  Indeed, I believe that if the Cisco/Linksys violations had not been a
  center of public ridicule in 2003 when I (then at the FSF) was in the
  midst of negotiating with them for compliance, we would not have ended
  up with such
  a long
  saga
  to resolution.

• Do contact the copyright holders, or their designated
  enforcement agents. Since
  the GPL
  is a copyright license, if the violator fails to comply on their own,
  only the copyright holder (typically) has the power to enforce the
  license⁰.
  Here’s a list of contact addresses that I know for reporting various
  violations (if you know more such addresses, please let me know and I’ll
  add them here):

  • Linux, BusyBox, Samba, Mercurial, uClibc: <[email protected]&gt
    (this address is primarily answered by me currently)
  • FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc,
    binutils): <[email protected]>
  • iptables, netfilter, mtd, initrd and
    msdosfs: <[email protected]>
    (note: gpl-violations.org is no longer active so this address might no
    longer work)
  • XviD: <[email protected]>

  If the GPL’d project you’ve found a violation on isn’t on the list above,
  just find email addresses of people with commit access to the repository
  for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS
  files. It’s better not to post the violation to a public discussion list
  for the project, as that’s just “going public”.

• Never treat a “community violator” the same way as a
  for-profit violator. I believe there is a fundamental difference
  between someone who makes a profit during the act of infringement than
  someone who merely seeks to contribute as a volunteer and screws
  something up. There isn’t a perfect line between the two — it’s a
  spectrum. However, those who don’t make any money from their
  infringement are probably just confused community members who
  misunderstood the GPL and deserve pure education and non-aggressive
  enforcement. Those who make money from the infringement deserve some
  friendly education too, of course, but ultimately they are making a
  profit by ignoring the rights of their users. I think these situations
  are fundamentally different, and deserve different tactics.

• Once you’ve reported a violation, please be patient with those of us
  doing enforcement. There are always hundreds of GPL violations that
  need action, and there are very few of us engaged in regular and active
  enforcement. Also, most of us try to get compliance not just on the
  copyrights we represent, but all GPL’d software. (This behooves both
  the software freedom community and the violator, as the former wants to
  see broad compliance, and the latter doesn’t want to deal with each
  copyright holder individually). Thus, it takes much time and effort to
  do each enforcement action. So, when you report a new violation, it
  might take some time for the situation to resolve.

• Do try your best to request source from the violator
  on your own. While making the violation public doesn’t help, inquiring
  privately does often help. If you have received distribution of a
  binary that you think is GPL’d or LGPL’d (or used a network service that
  you think is AGPL’d), do write to the violator (typically best to use the
  technical support channels) and ask for the complete and corresponding
  source code. Be as polite and friendly as possible, and always assume
  it is their intention to comply until you have specific evidence that
  they don’t intend to do so.

• Share as much good information with the violator as you can to
  encourage their compliance. My colleagues and
  I wrote A
  Practical Guide to GPL Compliance for just this purpose.

We need a careful balance regarding GPL enforcement. Remember that the
primary goal of the GPL is encourage more software freedom in the world.
For many violators, the first experience the violator has with FLOSS is
an enforcement action. We therefore must ensure that enforcement action
is reasonable and friendly. I view every GPL violator as a potential
FLOSS contributor, and try my best to open every enforcement action with
that attitude. I am human and thus sometimes become more frustrated
with uncooperative violators than I should be. However, striving for
kindness with violators only helps give a great image to the software
freedom community.

⁰In
some situations, there are a few possibilities for users that
exist if the copyright holder is unable or unwilling to enforce
the GPL. We’ve actually recently seen an interesting
successful enforcement by a user. I plan to blog in detail
about this soon.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/08/gpl-enforcement.html

In one of my favorite
movies, Office
Space, Tom Smykowski (one of the fired employees) has a
magic-eight-ball-style novelty product idea:
a “Jump
to Conclusions” mat. Sometimes, I watch discussions in the
software freedom community and think that, as a community, we’re all
jumping around on one of these mats.

I find that people are most likely to do this when something seems
novel and exciting. I don’t really blame anyone for doing it; I do it
myself when I have discovered an exciting thing that’s new to me, even
if it’s well known by others. But, often, this new thing is actually
rather mundane, and it’s better to check in with the existing knowledge
about the idea before “jumping” to any conclusions. In
other words, the best square on the mat for us to land on is the one
that reads: Think again!

Meanwhile, as some who follow
my microblog know, I’ve
been on a mission in recent months to establish just how common and
mundane GPL violations are. Since 21 August 2009, I’ve been finding one
new GPL violating company per day (on average) and I am still on target
to find one per day for 365 days straight. When I tell this to people
who are new to GPL enforcement, they are surprised and impressed.
However, when I tell people who have done GPL enforcement themselves,
they usually say some version of: Am I supposed to be impressed by
that? Couldn’t a monkey do that? Fact is, the latter are a little
bit right: there are so many GPL violations that I might easily be able
to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I
believe firmly they should be addressed, and I continue to dedicate much
of my life to resolve them. However, finding yet another GPL violation
isn’t a huge and earth-shaking discovery. Indeed, it’s what I was doing
today to kill time while drinking my Sunday morning coffee.

I don’t mean to imply that I don’t appreciate greatly when folks find
new GPL violations. I think finding and reporting GPL violations is a
very valuable service, and I wouldn’t spend so much time finding them
myself if I didn’t value the work highly. But, the work is more akin to
closing annoying bugs than it is to launching a paradigm-shifting FLOSS
project. Closing bugs is an essential part of FLOSS development, but no
one blogs about every single bug they close (although maybe we do
microblog them ;).

Having this weekend witnessed another community tempest about a
potential GPL violation, I decided to share a few guidelines that I
encourage everyone to follow when finding a GPL violation. (In other
words, what follows are a some basic guidelines for reporting
violations; other such guides are also available
at the
FSF’s site
and the
gpl-violations.org site (which is now defunct, since gpl-violations.org is
no longer active.)

• Assume the violation is an oversight or an accident by the violator
  until you have clear evidence that tells you differently. I’d say
  that 98% of the violations I’ve ever worked on since 1998 have been
  unintentional and due primarily to negligence, not malice.

• Don’t go public first. Back around late 1999, when I
  found my first GPL violation from scratch, I wanted to post it to every
  mailing list I could find and shame that company that failed to respect
  and cooperate with the software freedom community. I’m glad that I
  didn’t do that, because I’ve since seen similar actions destroy the
  lines of communication with violators, and make resolution tougher.
  Indeed, I believe that if the Cisco/Linksys violations had not been a
  center of public ridicule in 2003 when I (then at the FSF) was in the
  midst of negotiating with them for compliance, we would not have ended
  up with such
  a long
  saga
  to resolution.

• Do contact the copyright holders, or their designated
  enforcement agents. Since
  the GPL
  is a copyright license, if the violator fails to comply on their own,
  only the copyright holder (typically) has the power to enforce the
  license⁰.
  Here’s a list of contact addresses that I know for reporting various
  violations (if you know more such addresses, please let me know and I’ll
  add them here):

  • Linux, BusyBox, Samba, Mercurial, uClibc: <[email protected]&gt
    (this address is primarily answered by me currently)
  • FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc,
    binutils): <[email protected]>
  • iptables, netfilter, mtd, initrd and
    msdosfs: <[email protected]>
    (note: gpl-violations.org is no longer active so this address might no
    longer work)
  • XviD: <[email protected]>

  If the GPL’d project you’ve found a violation on isn’t on the list above,
  just find email addresses of people with commit access to the repository
  for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS
  files. It’s better not to post the violation to a public discussion list
  for the project, as that’s just “going public”.

• Never treat a “community violator” the same way as a
  for-profit violator. I believe there is a fundamental difference
  between someone who makes a profit during the act of infringement than
  someone who merely seeks to contribute as a volunteer and screws
  something up. There isn’t a perfect line between the two — it’s a
  spectrum. However, those who don’t make any money from their
  infringement are probably just confused community members who
  misunderstood the GPL and deserve pure education and non-aggressive
  enforcement. Those who make money from the infringement deserve some
  friendly education too, of course, but ultimately they are making a
  profit by ignoring the rights of their users. I think these situations
  are fundamentally different, and deserve different tactics.

• Once you’ve reported a violation, please be patient with those of us
  doing enforcement. There are always hundreds of GPL violations that
  need action, and there are very few of us engaged in regular and active
  enforcement. Also, most of us try to get compliance not just on the
  copyrights we represent, but all GPL’d software. (This behooves both
  the software freedom community and the violator, as the former wants to
  see broad compliance, and the latter doesn’t want to deal with each
  copyright holder individually). Thus, it takes much time and effort to
  do each enforcement action. So, when you report a new violation, it
  might take some time for the situation to resolve.

• Do try your best to request source from the violator
  on your own. While making the violation public doesn’t help, inquiring
  privately does often help. If you have received distribution of a
  binary that you think is GPL’d or LGPL’d (or used a network service that
  you think is AGPL’d), do write to the violator (typically best to use the
  technical support channels) and ask for the complete and corresponding
  source code. Be as polite and friendly as possible, and always assume
  it is their intention to comply until you have specific evidence that
  they don’t intend to do so.

• Share as much good information with the violator as you can to
  encourage their compliance. My colleagues and
  I wrote A
  Practical Guide to GPL Compliance for just this purpose.

We need a careful balance regarding GPL enforcement. Remember that the
primary goal of the GPL is encourage more software freedom in the world.
For many violators, the first experience the violator has with FLOSS is
an enforcement action. We therefore must ensure that enforcement action
is reasonable and friendly. I view every GPL violator as a potential
FLOSS contributor, and try my best to open every enforcement action with
that attitude. I am human and thus sometimes become more frustrated
with uncooperative violators than I should be. However, striving for
kindness with violators only helps give a great image to the software
freedom community.

⁰In
some situations, there are a few possibilities for users that
exist if the copyright holder is unable or unwilling to enforce
the GPL. We’ve actually recently seen an interesting
successful enforcement by a user. I plan to blog in detail
about this soon.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/08/gpl-enforcement.html

In one of my favorite
movies, Office
Space, Tom Smykowski (one of the fired employees) has a
magic-eight-ball-style novelty product idea:
a “Jump
to Conclusions” mat. Sometimes, I watch discussions in the
software freedom community and think that, as a community, we’re all
jumping around on one of these mats.

I find that people are most likely to do this when something seems
novel and exciting. I don’t really blame anyone for doing it; I do it
myself when I have discovered an exciting thing that’s new to me, even
if it’s well known by others. But, often, this new thing is actually
rather mundane, and it’s better to check in with the existing knowledge
about the idea before “jumping” to any conclusions. In
other words, the best square on the mat for us to land on is the one
that reads: Think again!

Meanwhile, as some who follow
my microblog know, I’ve
been on a mission in recent months to establish just how common and
mundane GPL violations are. Since 21 August 2009, I’ve been finding one
new GPL violating company per day (on average) and I am still on target
to find one per day for 365 days straight. When I tell this to people
who are new to GPL enforcement, they are surprised and impressed.
However, when I tell people who have done GPL enforcement themselves,
they usually say some version of: Am I supposed to be impressed by
that? Couldn’t a monkey do that? Fact is, the latter are a little
bit right: there are so many GPL violations that I might easily be able
to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I
believe firmly they should be addressed, and I continue to dedicate much
of my life to resolve them. However, finding yet another GPL violation
isn’t a huge and earth-shaking discovery. Indeed, it’s what I was doing
today to kill time while drinking my Sunday morning coffee.

I don’t mean to imply that I don’t appreciate greatly when folks find
new GPL violations. I think finding and reporting GPL violations is a
very valuable service, and I wouldn’t spend so much time finding them
myself if I didn’t value the work highly. But, the work is more akin to
closing annoying bugs than it is to launching a paradigm-shifting FLOSS
project. Closing bugs is an essential part of FLOSS development, but no
one blogs about every single bug they close (although maybe we do
microblog them ;).

Having this weekend witnessed another community tempest about a
potential GPL violation, I decided to share a few guidelines that I
encourage everyone to follow when finding a GPL violation. (In other
words, what follows are a some basic guidelines for reporting
violations; other such guides are also available
at the
FSF’s site
and the
gpl-violations.org site (which is now defunct, since gpl-violations.org is
no longer active.)

• Assume the violation is an oversight or an accident by the violator
  until you have clear evidence that tells you differently. I’d say
  that 98% of the violations I’ve ever worked on since 1998 have been
  unintentional and due primarily to negligence, not malice.

• Don’t go public first. Back around late 1999, when I
  found my first GPL violation from scratch, I wanted to post it to every
  mailing list I could find and shame that company that failed to respect
  and cooperate with the software freedom community. I’m glad that I
  didn’t do that, because I’ve since seen similar actions destroy the
  lines of communication with violators, and make resolution tougher.
  Indeed, I believe that if the Cisco/Linksys violations had not been a
  center of public ridicule in 2003 when I (then at the FSF) was in the
  midst of negotiating with them for compliance, we would not have ended
  up with such
  a long
  saga
  to resolution.

• Do contact the copyright holders, or their designated
  enforcement agents. Since
  the GPL
  is a copyright license, if the violator fails to comply on their own,
  only the copyright holder (typically) has the power to enforce the
  license⁰.
  Here’s a list of contact addresses that I know for reporting various
  violations (if you know more such addresses, please let me know and I’ll
  add them here):

  • Linux, BusyBox, Samba, Mercurial, uClibc: <[email protected]&gt
    (this address is primarily answered by me currently)
  • FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc,
    binutils): <[email protected]>
  • iptables, netfilter, mtd, initrd and
    msdosfs: <[email protected]>
    (note: gpl-violations.org is no longer active so this address might no
    longer work)
  • XviD: <[email protected]>

  If the GPL’d project you’ve found a violation on isn’t on the list above,
  just find email addresses of people with commit access to the repository
  for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS
  files. It’s better not to post the violation to a public discussion list
  for the project, as that’s just “going public”.

• Never treat a “community violator” the same way as a
  for-profit violator. I believe there is a fundamental difference
  between someone who makes a profit during the act of infringement than
  someone who merely seeks to contribute as a volunteer and screws
  something up. There isn’t a perfect line between the two — it’s a
  spectrum. However, those who don’t make any money from their
  infringement are probably just confused community members who
  misunderstood the GPL and deserve pure education and non-aggressive
  enforcement. Those who make money from the infringement deserve some
  friendly education too, of course, but ultimately they are making a
  profit by ignoring the rights of their users. I think these situations
  are fundamentally different, and deserve different tactics.

• Once you’ve reported a violation, please be patient with those of us
  doing enforcement. There are always hundreds of GPL violations that
  need action, and there are very few of us engaged in regular and active
  enforcement. Also, most of us try to get compliance not just on the
  copyrights we represent, but all GPL’d software. (This behooves both
  the software freedom community and the violator, as the former wants to
  see broad compliance, and the latter doesn’t want to deal with each
  copyright holder individually). Thus, it takes much time and effort to
  do each enforcement action. So, when you report a new violation, it
  might take some time for the situation to resolve.

• Do try your best to request source from the violator
  on your own. While making the violation public doesn’t help, inquiring
  privately does often help. If you have received distribution of a
  binary that you think is GPL’d or LGPL’d (or used a network service that
  you think is AGPL’d), do write to the violator (typically best to use the
  technical support channels) and ask for the complete and corresponding
  source code. Be as polite and friendly as possible, and always assume
  it is their intention to comply until you have specific evidence that
  they don’t intend to do so.

• Share as much good information with the violator as you can to
  encourage their compliance. My colleagues and
  I wrote A
  Practical Guide to GPL Compliance for just this purpose.

We need a careful balance regarding GPL enforcement. Remember that the
primary goal of the GPL is encourage more software freedom in the world.
For many violators, the first experience the violator has with FLOSS is
an enforcement action. We therefore must ensure that enforcement action
is reasonable and friendly. I view every GPL violator as a potential
FLOSS contributor, and try my best to open every enforcement action with
that attitude. I am human and thus sometimes become more frustrated
with uncooperative violators than I should be. However, striving for
kindness with violators only helps give a great image to the software
freedom community.

⁰In
some situations, there are a few possibilities for users that
exist if the copyright holder is unable or unwilling to enforce
the GPL. We’ve actually recently seen an interesting
successful enforcement by a user. I plan to blog in detail
about this soon.

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

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

• First, while Linux is easy to cram into a small space, particularly
  with BusyBox and uClibc, if you want things both really small and have a
  nice GUI API, it’s a bit tougher to get right. There is a reason the
  OpenMoko software stack was tough to get right and still has issues.
  Maemo, too, has had great struggles in its history that may not be fully
  overcome.
• Second, Google probably badly wanted Java as the native application
  language, due to its ubiquity. I dislike Java more than the average,
  but there’s no denying that nearly all undergraduate Computer Science
  students of the last ten years did most of their work in Java. Java is
  more foreign to most GNU/Linux developers than Python, Perl, Ruby and
  the like, but to the average programmer in the world, Java is the lingua
  franca.
• Third, and probably most troubling, Google wanted to have as little
  GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
  software freedom; it is to convince phone carriers and manufacturers to
  make Google’s proprietary applications the default mobile application
  set. The operating system is pure commodity to sell the proprietary
  applications. So, from Google’s perspective, the more permissively
  licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).