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.

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.

The collective thoughts of the interwebz