Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

I was intrigued to
read Greg
Kroah-Hartman’s analysis of what’s gone wrong with the Android fork of
Linux, and the discussion
that followed on lwn.net. Like Greg, I am hopeful that the Android
platform has a future that will work closely with upstream developers.
I also have my own agenda: I believe Android/Linux is the closest thing
we have to a viable fully FaiF phone operating system platform to take on the
proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg’s comments hint at a “new era” problem that
the FLOSS community hasn’t yet learned to solve. In the “old
days”, we had only big proprietary companies like Apple and
Microsoft that had little interest in ever touching copylefted software.
They didn’t want to make improvements and share them. Back then (and
today too) they prefer to consume all the permissively licensed Free
Software they can, and release/maintain proprietary forks for years.

I’m often critical of Google, but I must admit Google is (at least
sometimes) not afraid of dumping code on a regular basis to the
public, at least when it behooves them to do
it⁰. A
source-available Android/Linux helps Google, because Google executives
know the profit can be found in pushing proprietary user-space Android
application programs that link to Google’s advertising. They don’t want
to fight with Apple or Research in Motion to get their ads onto those
platforms; they’ll instead use Free Software to shift the underlying
platform.

So, in this case, the interests of software freedom align a bit with
Google’s for-profit motive. We want a fully FaiF phone operating
system, that also has a vibrant group of Free Software applications for
that operating system. While Google doesn’t care a bit about Free
Software applications on the phone, they need a readily available phone
operating system so that many hardware phone manufacturers will adopt
it. The FLOSS community and Google thus can work together here, in much
the same way various companies have always helped improve GNU/Linux on
the desktop because they thought it would foil their competitors (i.e.,
Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn’t
actually need our development help. Sure, Google needs the FLOSS
licenses we developed, and they need to get access to the upstream. But
they have that by default; all that knowledge and code is public.
Meanwhile, they can easily afford to have their engineers maintain
Android’s Linux fork indefinitely, and can more or less ignore Greg’s
suggestions for shepherding the code upstream. A small company with
limited resources would have to listen to Greg, lest the endeavor run
out of steam. But Google has plenty of steam.

We’re thus left appealing to Google’s sense of decency, goodwill,
collaboration and other software freedom principles that don’t necessarily
make an impact on their business. This can be a losing battle when
communicating with a for-profit company (particularly a publicly traded
one). They don’t have any self-interest nor for-profit reason to work
with upstream; they can hire as many good Linux hackers as they need to
keep their fork going.

This new era problem is actually harder than the old problem. In other
words, I can’t simply write an anti-Google blog post here like I’d write
an anti-Apple one. Google is releasing their changes, making them
available. They even have a public git repository for (at least) the
HTC Dream platform. True, I can and do criticize both Google and HTC
for making some hardware interface
libraries¹
proprietary, but that makes them akin to NVidia, not Microsoft and
Apple.

I don’t have an answer for this problem; I suggest only that our
community get serious about volunteer development and improvement of
Android/Linux. When Free Software started, we needed people to spend
their nights and weekends writing Free Software because there weren’t
any companies and for-profit business models to pay them yet. The
community even donated to Free Software charitable non-profits to
sponsor development that served the public. The need for that hasn’t
diminished; it’s actually increased. Now, there is more code
than ever available under FaiF licenses, but even more limited
not-for-profit community resources to shepherd that code in a
community-oriented direction. For-profit employers are beginning to
control the destiny of more community developers, and this will lead to
more scenarios like the one Greg describes. We need people to step
forward and say: I want to do what’s right with this code for this
particular userbase, not what’s right for one company. I hope someone
will see the value in this community-directed type of development and
fund it, but for the meantime, it has my nights and weekends. Just
about every famous FLOSS hacker today started with that attitude. We
need a bit more of that to go around.

(I don’t think I can end a blog post on this topic without giving a
little bit of kudos to a company whom I rarely agree with: Novell. As
near as I can tell, despite the many negative things Novell does, they
have created a position for Greg that allows him to do what’s right for
Linux with what (appears to be) minimal interference. They deserve
credit for this, and I think more companies that benefit from FLOSS
should create more positions like this. Or, even better, create such
positions through non-profit intermediaries, as the companies that fund
Linux Foundation do for Linus Torvalds.)

⁰Compare
this to Apple, which is so allergic to copyleft licenses that
they will do bizarre things that are clearly against their own
interest and more or less a waste of time merely to avoid GPL’d
codebases.

¹Updated:
I originally wrote drivers here,
but Greg
pointed out that there aren’t actually Linux drivers that
are proprietary. I am not sure what to
call these
various .so files which are clearly designed to interface with
the HTC hardware in some way, so I just called
them hardware interface libraries.

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

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/02/took-our-jobs.html

I could not think of anything but the South Park
quote, They took our jobs! when I read
today Black
Duck’s announcement of their patent, Resolving License
Dependencies For Aggregations of Legally-Protectable Content.

I’ve read through the patent, from the point of view of someone skilled
in this particular art. In fact, I’m specifically skilled in two
distinct arts related to this patent: computer programming and Free
Software license compatibility analysis. It’s from that perspective
that I took a look at this patent.

(BTW, the thing to always remember about reading patents is that the
really significant part isn’t the abstract, which often contains
pie-in-the-sky prose about what the patent covers. The claims are the
real details of the so-called “invention”.)

So, when I look closely at these claims, I am appalled to discover this
patent claims, as a novel invention, things that I’ve done regularly,
with a mix of my brain and a computer, since at least 1999. I quickly
came to the conclusion that this is yet another stupid patent granted by
the USPTO that it would be better to just ignore.

Indeed, ever since Amazon’s one-click patent, I’ve hated the inundation
of “look what stupid patent was granted today” slashdot
items. I think it’s a waste of time, generally speaking, since the
USPTO is granting many stupid software patents every single day. If we
spend our time gawking and saying how stupid they are, we don’t get any
real work done.

But, the (likely obvious) reason this caught my attention is that the
patent covers activities I’ve done regularly for so long. It gives me
this sick feeling in my stomach to read someone else claiming as an
invention something I’ve done and considered quite obvious for more than
a decade.

I’m not a patent agent (nor do I want to be — spending a week of
my life studying for a silly exam to get some credential hasn’t been
attractive to me since I got my Master’s degree), but honestly, I can’t
see how this patented process isn’t obvious to everyone skilled in the
arts of FLOSS license evaluation and computer programming. Indeed, the
process described is so simple-minded, that it’s a waste of time in my
view to spend time writing a software system to do it. With a few one-off
10-line Perl programs and a few greps, I’ve had a computer assist me
with processes like this one many times since the late 1990s.

I do feel some shame that I’ve now contributed to the “hey,
everyone, let’s gawk at this silly pointless surely-invalid
patent” rant. I guess that I have new sympathy for website
designers who were so personally offended regarding the Amazon one-click
patent. I can now confirm first-hand: it does really feel different
when the patent claims seem close to an activity you’ve engaged in
yourself for many years prior to the patent application. It’s when the
horribleness of the software patent system starts to really hit
home.

The saddest part, though, is that Black Duck again shows itself as a
company whose primary goal is to prey on people’s fear of software
freedom. They make proprietary software and acquire software patents
with the primary goal of scaring people into buying stuff they
probably don’t need. I’ve spent a lot more time working regularly on
FLOSS license compliance than anyone who has ever worked at Black Duck.
Simply put, coming into (and staying in) compliance is a much simpler
process than they say, and can be done easily without the use of
overpriced proprietary analysis of codebases.