GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I’d Be Worried

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/13/gplv3-agplv3-adoption.html

Since the release of GPLv3,
technology pundits have been opining about how adoption is unlikely,
usually citing Linux’s still-GPLv2 status as (often their only)
example. Even though I’m a pro-GPLv3 (and, specifically, pro-AGPLv3)
advocate, I have never been troubled by slow adoption, as long as it
remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free,
Libre and Open Source Software (FLOSS) projects do not always have the
most perfectly organized of copyright inventories, nor is the licensing
policy of the project the daily, primary focus of the developers.
Indeed, most developers have traditionally seen a licensing decision as
something you think about once and never revisit!

In some cases, such as with many of the packages in FSF’s GNU project,
there is a single entity copyright holder with a policy agenda, and such
organizations can (and did) immediately relicense large codebases under
GPLv3. However, in most projects, individual contributors keep their
own copyrights, and the relicensing takes time and discussion, which
must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or
GPLv3-only, basically instantaneously. However, wholesale relicensing
by a project leader would be downright rude. We’re a consensus-driven
community, and any project leader worth her title would not unilaterally
relicense without listening to the community. In fact, it’s somewhat
unlikely a project leader would relicense any existing
GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that
matter) without the consent of the contributor who holds those
copyrights. Even though that consent isn’t needed, getting it anyway is
a nice, consensus-building thing to do.

In fact, I think most projects prefer to
slowly change the license in various subparts of the work, as those
parts are changed and improved. That approach saves time from having to
do a “bombing run” patch that changes all the notices across
the project, and also reflects reality a bit
better0.

Of course, once you change one copyrightable part of a larger work to
GPLv3-or-later, the effective license of the whole work is
GPLv3-or-later, even if some parts could be extracted and distributed
under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have
started taking patches licensed under
GPLv3-or-later have effectively migrated to
GPLv31.
This fact alone, BTW, is why I believe strongly
that GPLv3 adoption statistics
sites (like Palamida’s) have counts that underestimate adoption. Such sites are almost
surely undercounting this phenomena. (It’s interesting to note that
even with such likely undercounting, Palamida’s numbers show a
sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for
a project that undertakes it. Such relicensing requires some hard work,
as a project leader will have to account for the copyright inventory and
ensure that she has permission to relicense. This job, while arduous,
is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to
get this done. Recently, I began
using git more regularly. I noticed
that Linus
designed git’s
license to leave open an easily implemented possibility for future
GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for
GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are,
in essence, a form of legislation that each project constructs for
itself. One “country” (i.e., the GNU project) has changed
all its “laws” quickly because it’s located on the epicenter
of where those “laws” were drafted. Indeed, most of us who
were deeply involved with the GPLv3 process were happy to change
quickly, because we watched the license construction happen
draft-by-draft, and we understood deeply the policy questions and how
they were addressed.

However, most FLOSS developers aren’t FLOSS licensing wonks like I and
my colleagues at the FSF are. So, we always understood
that developers would need time to grok the new license, and that they
would prefer to wait for its final release before they bothered. (Not
everyone wants to “run the daily snapshot in production”,
after all.) The developers should indeed take their time. As a
copyleft advocate, I’d never want a project to pick new rules they
aren’t ready for, or set legal terms they don’t fully understand
yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and
reasoned approach. Pundits can keep saying that the new license has
failed, but I’m not going take those comments seriously until the
pundits can prove that this linear growth — a product of each
project weighing the options slowly and carefully to come a decision
and then starting the slow migration — has ended. For
the moment, though, we seem right on course.

0Merely replacing the
existing GPLv2-or-later notice to read “GPLv3-or-later” (or
GPLv3-only) has little effect. In our highly-archived Internet world, the
code that was under GPLv2-or-later will always be available somewhere.
Since GPLv2 is irrevocable, you can’t take away someone’s permanent right
to copy, modify, distribute the work under GPLv2. So, until you actually
change the code, the benefit of a relicense is virtually non-existent.
Indeed, its only actual value is to remind your co-developers of the plan
to license as GPLv3-or-later going forward, and make it easy for them to
license their changes under GPLv3-or-later.

1I also
suspect that many projects that are doing this may not be clearly
explaining the overall licensing of the project to their users. A
side-project that I work on during the weekends
called PokerSource is actually in
the midst of slow migration from GPLv3-or-later to AGPLv3-or-later.
I
have carefully explained our license migration and its implications in
the toplevel LICENSE file, and encourage other projects
to follow that example.

Automatic Backtrace Generation

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/automatic-backtrace.html

Ubuntu has Apport. Fedora has nothing. That sucks big time.

Here’s the result of a few minutes of hacking up something similar to Apport based on the awesome (and much underused) Frysk debugging tool kit. It doesn’t post any backtraces on any Internet servers and has no fancy UI — but it automatically dumps a stacktrace of every crashing process on the system to syslog and stores all kinds of data in /tmp/core.*/ for later inspection.

#!/bin/bash
set -e
export PATH=/sbin:/bin:/usr/sbin:/usr/bin
DIR="/tmp/core.$1.$2"
umask 077
mkdir "$DIR"
cat > "$DIR/core"
exec &> "$DIR/dump.log"
set +e
echo "$1" > "$DIR/pid"
echo "$2" > "$DIR/timestamp"
echo "$3" > "$DIR/uid"
echo "$4" > "$DIR/gid"
echo "$5" > "$DIR/signal"
echo "$6" > "$DIR/hostname"
set -x
fauxv "$DIR/core" > "$DIR/auxv"
fexe "$DIR/core" > "$DIR/exe"
fmaps "$DIR/core" > "$DIR/maps"
PKGS=`/usr/bin/fdebuginfo "$DIR/core" | grep "\-\-\-" | cut -d ' ' -f 1 | sort | uniq | grep '^/'| xargs rpm -qf | sort | uniq`
[ "x$PKGS" != x ] && debuginfo-install -y $PKGS
fstack -rich "$DIR/core" > "$DIR/fstack"
set +x
(
	echo "Application `cat "$DIR/exe"` (pid=$1,uid=$3,gid=$4) crashed with signal $5."
	echo "Stack trace follows:"
	cat "$DIR/fstack"
	echo "Auxiliary vector:"
	cat "$DIR/auxv"
	echo "Maps:"
	cat "$DIR/maps"
	echo "For details check $DIR"
) | logger -p local6.info -t "frysk-core-dump-$1"

Copy that into a file $SOMEWHERE/frysk-core-dump. Then do a chmod +x $SOMEWHERE/frysk-core-dump and a chown root:root $SOMEWHERE/frysk-core-dump. Now, tell the kernel that core dumps should be handed to this script:

# echo "|$SOMEWHERE/frysk-core-dump %p %t %u %g %s %h" > /proc/sys/kernel/core_pattern

Finally, increase RLIMIT_CORE to actually enable core dumps. ulimit -c
unlimited is a good idea. This will enable them only for your shell and
everything it spawns. In /etc/security/limits.conf you can enable
them for all users. I haven’t found out yet how to enable them globally
in Fedora though, i.e. for every single process that is started after boot including system daemons.

You can test this with running sleep 4711 and then dumping core with C-\. The stacktrace should appear right-away in /var/log/messages.

This script will automatically try to install the debugging symbols for the crashing application via yum. In some cases it hence might take a while until the backtrace appears in syslog.

Don’t forget to install Frysk before trying this script!

You can’t believe how useful this script is. Something crashed and the backtrace is already waiting for you! It’s a bugfixer’s wet dream.

I am a bit surprised though that noone else came up with this before me. Or maybe I am just too dumb to use Google properly?

People of the Free World [1]!

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/free-sound-themes.html

GNOME 2.24 supports XDG
sound themes. Unfortunately however right now there is only a single sound
theme in existence: the sound-theme-freedesktop
— which is pretty basic.

Help us change this! There are many web sites like art.gnome.org which provide a large selection
of graphical themes for Gtk+, Metacity, icon sets and so on. We want to see a similarly large selection of sound themes available! And we’d like you to contribute to this!

How do you prepare sound themes? Read the XDG Sound Theming
and the XDG Sound
Naming specifications. Start with basing your work on the aforementioned sound-theme-freedesktop.
And then just go ahead!

Please note that only subset of the sounds listed in the Sound Naming
Specification is currently hooked up properly — i.e. generated when “input
feedback” is enabled or triggered by applications. Nonetheless it makes sense
to include them in your theme, because eventually they will be hooked up.

When you put a theme together, make sure that you only select sounds that
have a sensible Free Software license — or if you have produced them yourself
you pick a good license yourself. GPLv2+, LGPLv2+, CC-BY-SA 3.0 and CC-BY 3.0
are good choices.

Not everyone is as lucky as Richard Hughes and has a mom who is
practically an endless source of special effect sounds. If your mom sucks then
don’t despair! The OLPC team has compiled a huge set of Free sounds
that is waiting to be made an XDG sound theme. I am eagerly looking forward to your sound
themes that make use of “The Berklee Sampling
Archive – Volume 13 – synthesizer – fx (126 samples) spaceships, lasers,
explosions, machineguns, glisses” to start a war in space each time you
click a button on your screen![1]

Footnotes

[1] Free as in free desktops that is.

[2] OK, to be honest I am not actually that eagerly looking forward to that. Spacewar-at-your-fingertips is pretty lame in comparison to a theme called “Richard’s Mom”[3].

[3] You have no idea what all those Hughsie’s-Mom-jokes are about? Then listen to the sound files that are shipped with gnome-power-manager!

Responses to my Audio API Guide

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/guide-to-sound-apis-followup.html

My Audio API guide got quite a few responses.

The Good

Takashi
likes it. And so
does David. Which is great because both are key people in the Linux
multimedia community.

It made it to LWN. I sincerely
and humbly hope this is not going to stay the only news site picking this up.
😉

The safe ALSA part of the recommendations will most likely be added to the ALSA documentation soon. The GNOME-relevent part I will be adding to the GNOME platform overview.

The Bad

Aaron
basically likes it, although he appears disappointed that KDE’s and Qt’s
Phonon wasn’t mentioned more positively. Aaron is very fair in his criticism.
Nonetheless I don’t think it is valid. My guide is not a list of alternatives.
It’s a list of recommendations. My recommendations. I do believe that my
recommendations very much match the mainstream of the opinions of the key
people in Linux multimedia and desktop audio. Of course I don’t nearly know
everyone of the key hackers in Linux multimedia. But I do know most of those
who are actively interested in collaboration, whose projects have a lot
mindshare and who attend the conferences that matter for Linux desktop audio.

Also see Christian’s comments on Aaron’s post.

The Ugly

It wasn’t my intention to start another GNOME-vs.-KDE flamefest.
Unfortunately a lot of people took this as great opportunity to troll at the
various blog comment forums. I guess it is inevitable that some of those whose
favourite software is not listed on a recommendation guide like this start to
clamour about that. It’s a pity not everyone who thinks I am treating KDE
unfairly criticises that as fairly and reasonable as Aaron. Anyway, I humbly take this as a sign that
people do consider this guide to be relevant and much needed. 😉

Everybody Loves Pretty Graphics

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/the-linux-audio-stack.html

As kind of a followup to my Guide to Linux
Sound APIs here’re some pretty graphics I just drew. (At least “pretty” to
the degree of my limited drawing abilities). It’s a block diagram depicting the
Linux audio stack. A lot of people already drew something similar, and often
enough the result was horribly complicated and — in its conclusion
disappointing. So, here’s my try:

Linux Audio Stack

The components interface each other across the horizontal lines. The
vertical lines seperate unrelated components. The drawing only includes
modern, supported APIs and systems as described in the aforementioned blog
article. It (hopefully) shows that things in the Linux audio world are not
all that bad at all and we have workable answers for most questions without
too much complexity, although they might not entirely make everyone overly
happy.

In an outburst of bias I completely ommited KDE-specific technologies from
this drawing. I guess even if I would have included them it’d be called biased
anyway, so why bother? Also, they would have distracted the reader and complicated the
drawing considerably due to KDE’s affection for pluggable backends. So: if you
care about KDE, please ignore this diagram.

A Guide Through The Linux Sound API Jungle

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/guide-to-sound-apis.html

At the Audio MC at the Linux Plumbers Conference one
thing became very clear: it is very difficult for programmers to
figure out which audio API to use for which purpose and which API not
to use when doing audio programming on Linux. So here’s my try to
guide you through this jungle:

What do you want to do?

I want to write a media-player-like application!
Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)
I want to add event sounds to my application!
Use libcanberra, install your sound files according to the XDG Sound Theming/Naming Specifications! (Unless your focus is only KDE in which case KNotify might be an alternative although it has a different focus.)
I want to do professional audio programming, hard-disk recording, music synthesizing, MIDI interfacing!
Use JACK and/or the full ALSA interface.
I want to do basic PCM audio playback/capturing!
Use the safe ALSA subset.
I want to add sound to my game!
Use the audio API of SDL for full-screen games, libcanberra for simple games with standard UIs such as Gtk+.
I want to write a mixer application!
Use the layer you want to support directly: if you want to support enhanced desktop software mixers, use the PulseAudio volume control APIs. If you want to support hardware mixers, use the ALSA mixer APIs.
I want to write audio software for the plumbing layer!
Use the full ALSA stack.
I want to write audio software for embedded applications!
For technical appliances usually the safe ALSA subset is a good choice, this however depends highly on your use-case.

You want to know more about the different sound APIs?

GStreamer
GStreamer is the de-facto
standard media streaming system for Linux desktops. It supports decoding and
encoding of audio and video streams. You can use it for a wide range of
purposes from simple audio file playback to elaborate network
streaming setups. GStreamer supports a wide range of CODECs and audio
backends. GStreamer is not particularly suited for basic PCM playback
or low-latency/realtime applications. GStreamer is portable and not
limited in its use to Linux. Among the supported backends are ALSA, OSS, PulseAudio. [Programming Manuals and References]
libcanberra
libcanberra
is an abstract event sound API. It implements the XDG
Sound Theme and Naming Specifications. libcanberra is a blessed
GNOME dependency, but itself has no dependency on GNOME/Gtk/GLib and can be
used with other desktop environments as well. In addition to an easy
interface for playing sound files, libcanberra provides caching
(which is very useful for networked thin clients) and allows passing
of various meta data to the underlying audio system which then can be
used to enhance user experience (such as positional event sounds) and
for improving accessibility. libcanberra supports multiple backends
and is portable beyond Linux. Among the supported backends are ALSA, OSS, PulseAudio, GStreamer. [API Reference]
JACK
JACK is a sound system for
connecting professional audio production applications and hardware
output. It’s focus is low-latency and application interconnection. It
is not useful for normal desktop or embedded use. It is not an API
that is particularly useful if all you want to do is simple PCM
playback. JACK supports multiple backends, although ALSA is best
supported. JACK is portable beyond Linux. Among the supported backends are ALSA, OSS. [API Reference]
Full ALSA
ALSA is the Linux API
for doing PCM playback and recording. ALSA is very focused on
hardware devices, although other backends are supported as well (to a
limit degree, see below). ALSA as a name is used both for the Linux
audio kernel drivers and a user-space library that wraps these. ALSA — the library — is
comprehensive, and portable (to a limited degree). The full ALSA API
can appear very complex and is large. However it supports almost
everything modern sound hardware can provide. Some of the
functionality of the ALSA API is limited in its use to actual hardware
devices supported by the Linux kernel (in contrast to software sound
servers and sound drivers implemented in user-space such as those for
Bluetooth and FireWire audio — among others) and Linux specific
drivers. [API
Reference]
Safe ALSA
Only a subset of the full ALSA API works on all backends ALSA
supports. It is highly recommended to stick to this safe subset
if you do ALSA programming to keep programs portable, future-proof and
compatible with sound servers, Bluetooth audio and FireWire audio. See
below for more details about which functions of ALSA are considered
safe. The safe ALSA API is a suitable abstraction for basic,
portable PCM playback and recording — not just for ALSA kernel driver
supported devices. Among the supported backends are ALSA kernel driver
devices, OSS, PulseAudio, JACK.
Phonon and KNotify
Phonon is high-level
abstraction for media streaming systems such as GStreamer, but goes a
bit further than that. It supports multiple backends. KNotify is a
system for “notifications”, which goes beyond mere event
sounds. However it does not support the XDG Sound Theming/Naming
Specifications at this point, and also doesn’t support caching or
passing of event meta-data to an underlying sound system. KNotify
supports multiple backends for audio playback via Phonon. Both APIs
are KDE/Qt specific and should not be used outside of KDE/Qt
applications. [Phonon API Reference] [KNotify API Reference]
SDL
SDL is a portable API
primarily used for full-screen game development. Among other stuff it
includes a portable audio interface. Among others SDL support OSS,
PulseAudio, ALSA as backends. [API Reference]
PulseAudio
PulseAudio is a sound system
for Linux desktops and embedded environments that runs in user-space
and (usually) on top of ALSA. PulseAudio supports network
transparency, per-application volumes, spatial events sounds, allows
switching of sound streams between devices on-the-fly, policy
decisions, and many other high-level operations. PulseAudio adds a glitch-free
audio playback model to the Linux audio stack. PulseAudio is not
useful in professional audio production environments. PulseAudio is
portable beyond Linux. PulseAudio has a native API and also supports
the safe subset of ALSA, in addition to limited,
LD_PRELOAD-based OSS compatibility. Among others PulseAudio supports
OSS and ALSA as backends and provides connectivity to JACK. [API
Reference]
OSS
The Open Sound System is a
low-level PCM API supported by a variety of Unixes including Linux. It
started out as the standard Linux audio system and is supported on
current Linux kernels in the API version 3 as OSS3. OSS3 is considered
obsolete and has been fully replaced by ALSA. A successor to OSS3
called OSS4 is available but plays virtually no role on Linux and is
not supported in standard kernels or by any of the relevant
distributions. The OSS API is very low-level, based around direct
kernel interfacing using ioctl()s. It it is hence awkward to use and
can practically not be virtualized for usage on non-kernel audio
systems like sound servers (such as PulseAudio) or user-space sound
drivers (such as Bluetooth or FireWire audio). OSS3’s timing model
cannot properly be mapped to software sound servers at all, and is
also problematic on non-PCI hardware such as USB audio. Also, OSS does
not do sample type conversion, remapping or resampling if
necessary. This means that clients that properly want to support OSS
need to include a complete set of converters/remappers/resamplers for
the case when the hardware does not natively support the requested
sampling parameters. With modern sound cards it is very common to
support only S32LE samples at 48KHz and nothing else. If an OSS client
assumes it can always play back S16LE samples at 44.1KHz it will thus
fail. OSS3 is portable to other Unix-like systems, various differences
however apply. OSS also doesn’t support surround sound and other
functionality of modern sounds systems properly. OSS should be
considered obsolete and not be used in new applications. ALSA and
PulseAudio have limited LD_PRELOAD-based compatibility with OSS. [Programming Guide]

All sound systems and APIs listed above are supported in all
relevant current distributions. For libcanberra support the newest
development release of your distribution might be necessary.

All sound systems and APIs listed above are suitable for
development for commercial (read: closed source) applications, since
they are licensed under LGPL or more liberal licenses or no client
library is involved.

You want to know why and when you should use a specific sound API?

GStreamer
GStreamer is best used for very high-level needs: i.e. you want to
play an audio file or video stream and do not care about all the tiny
details down to the PCM or codec level.
libcanberra
libcanberra is best used when adding sound feedback to user input
in UIs. It can also be used to play simple sound files for
notification purposes.
JACK
JACK is best used in professional audio production and where interconnecting applications is required.
Full ALSA
The full ALSA interface is best used for software on “plumbing layer” or when you want to make use of very specific hardware features, which might be need for audio production purposes.
Safe ALSA
The safe ALSA interface is best used for software that wants to output/record basic PCM data from hardware devices or software sound systems.
Phonon and KNotify
Phonon and KNotify should only be used in KDE/Qt applications and only for high-level media playback, resp. simple audio notifications.
SDL
SDL is best used in full-screen games.
PulseAudio
For now, the PulseAudio API should be used only for applications
that want to expose sound-server-specific functionality (such as
mixers) or when a PCM output abstraction layer is already available in
your application and it thus makes sense to add an additional backend
to it for PulseAudio to keep the stack of audio layers minimal.
OSS
OSS should not be used for new programs.

You want to know more about the safe ALSA subset?

Here’s a list of DOS and DONTS in the ALSA API if you care about
that you application stays future-proof and works fine with
non-hardware backends or backends for user-space sound drivers such as
Bluetooth and FireWire audio. Some of these recommendations apply for
people using the full ALSA API as well, since some functionality
should be considered obsolete for all cases.

If your application’s code does not follow these rules, you must have
a very good reason for that. Otherwise your code should simply be considered
broken!

DONTS:

  • Do not use “async handlers”, e.g. via
    snd_async_add_pcm_handler() and friends. Asynchronous
    handlers are implemented using POSIX signals, which is a very
    questionable use of them, especially from libraries and plugins. Even
    when you don’t want to limit yourself to the safe ALSA subset
    it is highly recommended not to use this functionality. Read
    this for a longer explanation why signals for audio IO are
    evil.
  • Do not parse the ALSA configuration file yourself or with
    any of the ALSA functions such as snd_config_xxx(). If you
    need to enumerate audio devices use snd_device_name_hint()
    (and related functions). That
    is the only API that also supports enumerating non-hardware audio
    devices and audio devices with drivers implemented in userspace.
  • Do not parse any of the files from
    /proc/asound/. Those files only include information about
    kernel sound drivers — user-space plugins are not listed there. Also,
    the set of kernel devices might differ from the way they are presented
    in user-space. (i.e. sub-devices are mapped in different ways to
    actual user-space devices such as surround51 an suchlike.
  • Do not rely on stable device indexes from ALSA. Nowadays
    they depend on the initialization order of the drivers during boot-up
    time and are thus not stable.
  • Do not use the snd_card_xxx() APIs. For
    enumerating use snd_device_name_hint() (and related
    functions). snd_card_xxx() is obsolete. It will only list
    kernel hardware devices. User-space devices such as sound servers,
    Bluetooth audio are not included. snd_card_load() is
    completely obsolete in these days.
  • Do not hard-code device strings, especially not
    hw:0 or plughw:0 or even dmix — these devices define no channel
    mapping and are mapped to raw kernel devices. It is highly recommended
    to use exclusively default as device string. If specific
    channel mappings are required the correct device strings should be
    front for stereo, surround40 for Surround 4.0,
    surround41, surround51, and so on. Unfortunately at
    this point ALSA does not define standard device names with channel
    mappings for non-kernel devices. This means default may only
    be used safely for mono and stereo streams. You should probably prefix
    your device string with plug: to make sure ALSA transparently
    reformats/remaps/resamples your PCM stream for you if the
    hardware/backend does not support your sampling parameters
    natively.
  • Do not assume that any particular sample type is supported
    except the following ones: U8, S16_LE, S16_BE, S32_LE, S32_BE,
    FLOAT_LE, FLOAT_BE, MU_LAW, A_LAW.
  • Do not use snd_pcm_avail_update() for
    synchronization purposes. It should be used exclusively to query the
    amount of bytes that may be written/read right now. Do not use
    snd_pcm_delay() to query the fill level of your playback
    buffer. It should be used exclusively for synchronisation
    purposes. Make sure you fully understand the difference, and note that
    the two functions return values that are not necessarily directly
    connected!
  • Do not assume that the mixer controls always know dB information.
  • Do not assume that all devices support MMAP style buffer access.
  • Do not assume that the hardware pointer inside the (possibly mmaped) playback buffer is the actual position of the sample in the DAC. There might be an extra latency involved.
  • Do not try to recover with your own code from ALSA error conditions such as buffer under-runs. Use snd_pcm_recover() instead.
  • Do not touch buffering/period metrics unless you have
    specific latency needs. Develop defensively, handling correctly the
    case when the backend cannot fulfill your buffering metrics
    requests. Be aware that the buffering metrics of the playback buffer
    only indirectly influence the overall latency in many
    cases. i.e. setting the buffer size to a fixed value might actually result in
    practical latencies that are much higher.
  • Do not assume that snd_pcm_rewind() is available and works and to which degree.
  • Do not assume that the time when a PCM stream can receive
    new data is strictly dependant on the sampling and buffering
    parameters and the resulting average throughput. Always make sure to
    supply new audio data to the device when it asks for it by signalling
    “writability” on the fd. (And similarly for capturing)
  • Do not use the “simple” interface snd_spcm_xxx().
  • Do not use any of the functions marked as “obsolete”.
  • Do not use the timer, midi, rawmidi, hwdep subsystems.

DOS:

  • Use snd_device_name_hint() for enumerating audio devices.
  • Use snd_smixer_xx() instead of raw snd_ctl_xxx()
  • For synchronization purposes use snd_pcm_delay().
  • For checking buffer playback/capture fill level use snd_pcm_update_avail().
  • Use snd_pcm_recover() to recover from errors returned by any of the ALSA functions.
  • If possible use the largest buffer sizes the device supports to maximize power saving and drop-out safety. Use snd_pcm_rewind() if you need to react to user input quickly.

FAQ

What about ESD and NAS?
ESD and NAS are obsolete, both as API and as sound daemon. Do not develop for it any further.
ALSA isn’t portable!
That’s not true! Actually the user-space library is relatively portable, it even includes a backend for OSS sound devices. There is no real reason that would disallow using the ALSA libraries on other Unixes as well.
Portability is key to me! What can I do?
Unfortunately no truly portable (i.e. to Win32) PCM API is
available right now that I could truly recommend. The systems shown
above are more or less portable at least to Unix-like operating
systems. That does not mean however that there are suitable backends
for all of them available. If you care about portability to Win32 and
MacOS you probably have to find a solution outside of the
recommendations above, or contribute the necessary
backends/portability fixes. None of the systems (with the exception of
OSS) is truly bound to Linux or Unix-like kernels.
What about PortAudio?
I don’t think that PortAudio is very good API for Unix-like operating systems. I cannot recommend it, but it’s your choice.
Oh, why do you hate OSS4 so much?
I don’t hate anything or anyone. I just don’t think OSS4 is a
serious option, especially not on Linux. On Linux, it is also
completely redundant due to ALSA.
You idiot, you have no clue!
You are right, I totally don’t. But that doesn’t hinder me from recommending things. Ha!
Hey I wrote/know this tiny new project which is an awesome abstraction layer for audio/media!
Sorry, that’s not sufficient. I only list software here that is known to be sufficiently relevant and sufficiently well maintained.

Final Words

Of course these recommendations are very basic and are only intended to
lead into the right direction. For each use-case different necessities
apply and hence options that I did not consider here might become
viable. It’s up to you to decide how much of what I wrote here
actually applies to your application.

This summary only includes software systems that are considered
stable and universally available at the time of writing. In the
future I hope to introduce a more suitable and portable replacement
for the safe ALSA subset of functions. I plan to update this text
from time to time to keep things up-to-date.

If you feel that I forgot a use case or an important API, then
please contact me or leave a comment. However, I think the summary
above is sufficiently comprehensive and if an entry is missing I most
likely deliberately left it out.

(Also note that I am upstream for both PulseAudio and libcanberra and did some minor contributions to ALSA, GStreamer and some other of the systems listed above. Yes, I am biased.)

Oh, and please syndicate this, digg it. I’d like to see this guide to be well-known all around the Linux community. Thank you!

My take on the Plumbers Conference

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/lpc-summary.html

I just came back from the Linux
Plumbers Conference. As some of you might know I was doing an MC about Audio
there. Don Marti attended the track and wrote up an interesting article over at LWN.
It’s a recommended read, including the immense number of comments it already
resulted in. (I will try to reply to all comments coming up, in case you have questions — just post them over at LWN)

I must really say though that calling that article “It’s a mess” and
highlighting my critical comments on the situation this way makes me feel
slightly uncomfortable, though. Sure, we have some issues to fix and it’s the
words I chose at the conference — but it’s only part of the story. Things are
not really all that bad, and we have enough good stuff to focus on.

I enjoyed LPC, and especially the audio MC a lot. The discussions during the
MC were lively, focussed and very enlightening. Much better than at others
conferences I have been to the information flow was two-ways: instead of just
having a speaker who talks about stuff and attendees that listen to them, here
all talks were very interactive — a lot of people in the audience had
something to say, and the others did benefit from it.

LPC organization was flawless, Portland is awesome. The food was good, too.
To summarize: I am happy, very happy! I look forward for another iteration next year and hope we’ll be able to
have an audio MC then, too.

LPC organizers: rock on! Takashi, Jonathan: thank you very much for your
participation in the Audio MC!

(If you are not subscribed to LWN but want to read the article linked above, ping me, I can hand out a few free links. Alternatively, wait for thursday and it will be available for free.)

The collective thoughts of the interwebz