Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/20/podjango.html

I had yet to mention in my blog that I now co-host
a podcast at SFLC.
I found myself, as we launched the podcast last week, in a classic hacker
situation of having one project demand the need to write code for a
tangentially related project.

Specifically, we needed a way to easily publish show notes and
otherwise make available the podcast on the website and in RSS feeds.
Fortunately, we already had a few applications we’d written using Django. I looked briefly at django podcast, but
the interface was a bit complicated, and I didn’t like its (over)use of
templates to do most of the RSS feeding.

The small blogging application we’d hacked up for this blog was so
close to what we needed, that I simply decided to fork it and make it into
a small podcast publisher. It worked out well, and I’ve now launched a Free Software
project called podjango under the AGPLv3.

Most of the existing code will be quite obvious to any Django hacker.
The only interesting thing to note is that I made some serious effort for
the RSS
feeds. First, I heavily fleshed out the
minimal example for an iTunesFeed generator in the Django
documentation. It’s currently a bit specific to this podcast, but should be
easily abstracted. I did a good amount of research on the needed fields
for the iTunes
RSS and Media RSS
and what should be in them. (Those feedforall.com tutorials appear to be
the best I could find on this.)

Second, I did about six hours of work to build what I called SFLC’s ominbus RSS feed.
The most effort went into building an RSS feed that includes disparate
Django application components, but this
thread on query set manipulation from django-users referenced from Michael
Angela’s blog was very helpful. I was glad, actually, that the
ultimate solution centered around complicated features of Python. Being
an old-school Perl hacker, I love when the solution is obvious once you
learn a feature of the language that you didn’t know before. (Is that the
definition of programming language snobbery? 😉

It also turns out that Fabian
Scherschel (aka fabsh) had started working on on a Django podcast
application too, and he’s going to merge in his efforts with podjango. I
preemptively apologize publicly, BTW, that I didn’t reach out to the
django-podcast guys before starting a new project. However, I’m sure
fabsh and I both would be happy to cooperate with them if they want to try
to merge the codebases (although I don’t want to use a non-Free software
platform like Google Code to host any project I work on ;). Anyway, I
really think RSS feeds should be implemented using generators in Python
code rather than in templates, though, and I think the user interface
should be abstracted away from as many details for the DTD fields as
possible. Thus, it may turn out that we and django-podcast have
incompatible design goals.

Anyway, I hope the code we’ve released is useful, and I’m glad for
Fabian to take over as project lead. I need to move onto other projects,
and hope that others will be interested in generalizing and improving the
code under Fab’s leadership. I’m happy to help it along.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/20/podjango.html

I had yet to mention in my blog that I now co-host
a podcast at SFLC.
I found myself, as we launched the podcast last week, in a classic hacker
situation of having one project demand the need to write code for a
tangentially related project.

Specifically, we needed a way to easily publish show notes and
otherwise make available the podcast on the website and in RSS feeds.
Fortunately, we already had a few applications we’d written using Django. I looked briefly at django podcast, but
the interface was a bit complicated, and I didn’t like its (over)use of
templates to do most of the RSS feeding.

The small blogging application we’d hacked up for this blog was so
close to what we needed, that I simply decided to fork it and make it into
a small podcast publisher. It worked out well, and I’ve now launched a Free Software
project called podjango under the AGPLv3.

Most of the existing code will be quite obvious to any Django hacker.
The only interesting thing to note is that I made some serious effort for
the RSS
feeds. First, I heavily fleshed out the
minimal example for an iTunesFeed generator in the Django
documentation. It’s currently a bit specific to this podcast, but should be
easily abstracted. I did a good amount of research on the needed fields
for the iTunes
RSS and Media RSS
and what should be in them. (Those feedforall.com tutorials appear to be
the best I could find on this.)

Second, I did about six hours of work to build what I called SFLC’s ominbus RSS feed.
The most effort went into building an RSS feed that includes disparate
Django application components, but this
thread on query set manipulation from django-users referenced from Michael
Angela’s blog was very helpful. I was glad, actually, that the
ultimate solution centered around complicated features of Python. Being
an old-school Perl hacker, I love when the solution is obvious once you
learn a feature of the language that you didn’t know before. (Is that the
definition of programming language snobbery? 😉

It also turns out that Fabian
Scherschel (aka fabsh) had started working on on a Django podcast
application too, and he’s going to merge in his efforts with podjango. I
preemptively apologize publicly, BTW, that I didn’t reach out to the
django-podcast guys before starting a new project. However, I’m sure
fabsh and I both would be happy to cooperate with them if they want to try
to merge the codebases (although I don’t want to use a non-Free software
platform like Google Code to host any project I work on ;). Anyway, I
really think RSS feeds should be implemented using generators in Python
code rather than in templates, though, and I think the user interface
should be abstracted away from as many details for the DTD fields as
possible. Thus, it may turn out that we and django-podcast have
incompatible design goals.

Anyway, I hope the code we’ve released is useful, and I’m glad for
Fabian to take over as project lead. I need to move onto other projects,
and hope that others will be interested in generalizing and improving the
code under Fab’s leadership. I’m happy to help it along.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/20/podjango.html

I had yet to mention in my blog that I now co-host
a podcast at SFLC.
I found myself, as we launched the podcast last week, in a classic hacker
situation of having one project demand the need to write code for a
tangentially related project.

Specifically, we needed a way to easily publish show notes and
otherwise make available the podcast on the website and in RSS feeds.
Fortunately, we already had a few applications we’d written using Django. I looked briefly at django podcast, but
the interface was a bit complicated, and I didn’t like its (over)use of
templates to do most of the RSS feeding.

The small blogging application we’d hacked up for this blog was so
close to what we needed, that I simply decided to fork it and make it into
a small podcast publisher. It worked out well, and I’ve now launched a Free Software
project called podjango under the AGPLv3.

Most of the existing code will be quite obvious to any Django hacker.
The only interesting thing to note is that I made some serious effort for
the RSS
feeds. First, I heavily fleshed out the
minimal example for an iTunesFeed generator in the Django
documentation. It’s currently a bit specific to this podcast, but should be
easily abstracted. I did a good amount of research on the needed fields
for the iTunes
RSS and Media RSS
and what should be in them. (Those feedforall.com tutorials appear to be
the best I could find on this.)

Second, I did about six hours of work to build what I called SFLC’s ominbus RSS feed.
The most effort went into building an RSS feed that includes disparate
Django application components, but this
thread on query set manipulation from django-users referenced from Michael
Angela’s blog was very helpful. I was glad, actually, that the
ultimate solution centered around complicated features of Python. Being
an old-school Perl hacker, I love when the solution is obvious once you
learn a feature of the language that you didn’t know before. (Is that the
definition of programming language snobbery? 😉

It also turns out that Fabian
Scherschel (aka fabsh) had started working on on a Django podcast
application too, and he’s going to merge in his efforts with podjango. I
preemptively apologize publicly, BTW, that I didn’t reach out to the
django-podcast guys before starting a new project. However, I’m sure
fabsh and I both would be happy to cooperate with them if they want to try
to merge the codebases (although I don’t want to use a non-Free software
platform like Google Code to host any project I work on ;). Anyway, I
really think RSS feeds should be implemented using generators in Python
code rather than in templates, though, and I think the user interface
should be abstracted away from as many details for the DTD fields as
possible. Thus, it may turn out that we and django-podcast have
incompatible design goals.

Anyway, I hope the code we’ve released is useful, and I’m glad for
Fabian to take over as project lead. I need to move onto other projects,
and hope that others will be interested in generalizing and improving the
code under Fab’s leadership. I’m happy to help it along.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/20/podjango.html

I had yet to mention in my blog that I now co-host
a podcast at SFLC.
I found myself, as we launched the podcast last week, in a classic hacker
situation of having one project demand the need to write code for a
tangentially related project.

Specifically, we needed a way to easily publish show notes and
otherwise make available the podcast on the website and in RSS feeds.
Fortunately, we already had a few applications we’d written using Django. I looked briefly at django podcast, but
the interface was a bit complicated, and I didn’t like its (over)use of
templates to do most of the RSS feeding.

The small blogging application we’d hacked up for this blog was so
close to what we needed, that I simply decided to fork it and make it into
a small podcast publisher. It worked out well, and I’ve now launched a Free Software
project called podjango under the AGPLv3.

Most of the existing code will be quite obvious to any Django hacker.
The only interesting thing to note is that I made some serious effort for
the RSS
feeds. First, I heavily fleshed out the
minimal example for an iTunesFeed generator in the Django
documentation. It’s currently a bit specific to this podcast, but should be
easily abstracted. I did a good amount of research on the needed fields
for the iTunes
RSS and Media RSS
and what should be in them. (Those feedforall.com tutorials appear to be
the best I could find on this.)

Second, I did about six hours of work to build what I called SFLC’s ominbus RSS feed.
The most effort went into building an RSS feed that includes disparate
Django application components, but this
thread on query set manipulation from django-users referenced from Michael
Angela’s blog was very helpful. I was glad, actually, that the
ultimate solution centered around complicated features of Python. Being
an old-school Perl hacker, I love when the solution is obvious once you
learn a feature of the language that you didn’t know before. (Is that the
definition of programming language snobbery? 😉

It also turns out that Fabian
Scherschel (aka fabsh) had started working on on a Django podcast
application too, and he’s going to merge in his efforts with podjango. I
preemptively apologize publicly, BTW, that I didn’t reach out to the
django-podcast guys before starting a new project. However, I’m sure
fabsh and I both would be happy to cooperate with them if they want to try
to merge the codebases (although I don’t want to use a non-Free software
platform like Google Code to host any project I work on ;). Anyway, I
really think RSS feeds should be implemented using generators in Python
code rather than in templates, though, and I think the user interface
should be abstracted away from as many details for the DTD fields as
possible. Thus, it may turn out that we and django-podcast have
incompatible design goals.

Anyway, I hope the code we’ve released is useful, and I’m glad for
Fabian to take over as project lead. I need to move onto other projects,
and hope that others will be interested in generalizing and improving the
code under Fab’s leadership. I’m happy to help it along.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/20/podjango.html

I had yet to mention in my blog that I now co-host
a podcast at SFLC.
I found myself, as we launched the podcast last week, in a classic hacker
situation of having one project demand the need to write code for a
tangentially related project.

Specifically, we needed a way to easily publish show notes and
otherwise make available the podcast on the website and in RSS feeds.
Fortunately, we already had a few applications we’d written using Django. I looked briefly at django podcast, but
the interface was a bit complicated, and I didn’t like its (over)use of
templates to do most of the RSS feeding.

The small blogging application we’d hacked up for this blog was so
close to what we needed, that I simply decided to fork it and make it into
a small podcast publisher. It worked out well, and I’ve now launched a Free Software
project called podjango under the AGPLv3.

Most of the existing code will be quite obvious to any Django hacker.
The only interesting thing to note is that I made some serious effort for
the RSS
feeds. First, I heavily fleshed out the
minimal example for an iTunesFeed generator in the Django
documentation. It’s currently a bit specific to this podcast, but should be
easily abstracted. I did a good amount of research on the needed fields
for the iTunes
RSS and Media RSS
and what should be in them. (Those feedforall.com tutorials appear to be
the best I could find on this.)

Second, I did about six hours of work to build what I called SFLC’s ominbus RSS feed.
The most effort went into building an RSS feed that includes disparate
Django application components, but this
thread on query set manipulation from django-users referenced from Michael
Angela’s blog was very helpful. I was glad, actually, that the
ultimate solution centered around complicated features of Python. Being
an old-school Perl hacker, I love when the solution is obvious once you
learn a feature of the language that you didn’t know before. (Is that the
definition of programming language snobbery? 😉

It also turns out that Fabian
Scherschel (aka fabsh) had started working on on a Django podcast
application too, and he’s going to merge in his efforts with podjango. I
preemptively apologize publicly, BTW, that I didn’t reach out to the
django-podcast guys before starting a new project. However, I’m sure
fabsh and I both would be happy to cooperate with them if they want to try
to merge the codebases (although I don’t want to use a non-Free software
platform like Google Code to host any project I work on ;). Anyway, I
really think RSS feeds should be implemented using generators in Python
code rather than in templates, though, and I think the user interface
should be abstracted away from as many details for the DTD fields as
possible. Thus, it may turn out that we and django-podcast have
incompatible design goals.

Anyway, I hope the code we’ve released is useful, and I’m glad for
Fabian to take over as project lead. I need to move onto other projects,
and hope that others will be interested in generalizing and improving the
code under Fab’s leadership. I’m happy to help it along.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/11/20/podjango.html

I had yet to mention in my blog that I now co-host
a podcast at SFLC.
I found myself, as we launched the podcast last week, in a classic hacker
situation of having one project demand the need to write code for a
tangentially related project.

Specifically, we needed a way to easily publish show notes and
otherwise make available the podcast on the website and in RSS feeds.
Fortunately, we already had a few applications we’d written using Django. I looked briefly at django podcast, but
the interface was a bit complicated, and I didn’t like its (over)use of
templates to do most of the RSS feeding.

The small blogging application we’d hacked up for this blog was so
close to what we needed, that I simply decided to fork it and make it into
a small podcast publisher. It worked out well, and I’ve now launched a Free Software
project called podjango under the AGPLv3.

Most of the existing code will be quite obvious to any Django hacker.
The only interesting thing to note is that I made some serious effort for
the RSS
feeds. First, I heavily fleshed out the
minimal example for an iTunesFeed generator in the Django
documentation. It’s currently a bit specific to this podcast, but should be
easily abstracted. I did a good amount of research on the needed fields
for the iTunes
RSS and Media RSS
and what should be in them. (Those feedforall.com tutorials appear to be
the best I could find on this.)

Second, I did about six hours of work to build what I called SFLC’s ominbus RSS feed.
The most effort went into building an RSS feed that includes disparate
Django application components, but this
thread on query set manipulation from django-users referenced from Michael
Angela’s blog was very helpful. I was glad, actually, that the
ultimate solution centered around complicated features of Python. Being
an old-school Perl hacker, I love when the solution is obvious once you
learn a feature of the language that you didn’t know before. (Is that the
definition of programming language snobbery? 😉

It also turns out that Fabian
Scherschel (aka fabsh) had started working on on a Django podcast
application too, and he’s going to merge in his efforts with podjango. I
preemptively apologize publicly, BTW, that I didn’t reach out to the
django-podcast guys before starting a new project. However, I’m sure
fabsh and I both would be happy to cooperate with them if they want to try
to merge the codebases (although I don’t want to use a non-Free software
platform like Google Code to host any project I work on ;). Anyway, I
really think RSS feeds should be implemented using generators in Python
code rather than in templates, though, and I think the user interface
should be abstracted away from as many details for the DTD fields as
possible. Thus, it may turn out that we and django-podcast have
incompatible design goals.

Anyway, I hope the code we’ve released is useful, and I’m glad for
Fabian to take over as project lead. I need to move onto other projects,
and hope that others will be interested in generalizing and improving the
code under Fab’s leadership. I’m happy to help it along.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.

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
better⁰.

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
GPLv3¹.
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.

⁰Merely 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.

¹I 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.