Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/09/gpg-gen-key-decade.html

Today is an interesting anniversary (of sorts) for my cryptographic
infrastructure. Nine years ago today, I generated the 1024 bit DSA key,
DB41B387, that has been my GPG key every day since then. I remember
distinctly that on the 350 MhZ machine I used at the time, it took quite
a while to generate, even though I made sure the entropy pool remained
nice and full by pounding on the keyboard.

The horribleness of the
recent Debian vulnerability meant that I have spent a much time
this year pondering the pedigree my personal cryptographic
infrastructure. Of course, my key was far too old to have been
generated on a Debian-based system that had that particular
vulnerability. However, the issue that really troubled me this
past summer was this:

Some DSA keys may be compromised by only their use. A strong
key (i.e., generated with a ‘good’ OpenSSL) but used locally
on a machine with a ‘bad’ OpenSSL must be considered to be
compromised. This is due to an ‘attack’ on DSA that allows the
secret key to be found if the nonce used in the signature is reused or
known.

Not being particularly hard core on cryptographic knowledge — most of my expertise comes from only one class I took 11 years ago on
Encryption, Compression, and Secure Hashing in graduate school —
I found this alarming and tried my best to do some ancillary reading.
It seems that DSA keys, in many ways, are less than optimal. It seems
(to my mostly uneducated eye) in skimming academic papers that DSA keys
are tougher to deploy right and keep secure, which leads to these sorts
of possible problems.

I’ve resolved to switch entirely to RSA keys. The great thing about
RSA is its simplicity and ease of understanding. I grok factoring and
understand better the complexity situation of the factoring problem
(this time, from the two graduate courses I took on Complexity
Theory, so my comfort is more solid :). I also find it intriguing that
a child can learn how to factor in grade school, yet we can’t teach a
computer to do it efficiently. (By contrast, I didn’t learn the
discrete logarithm problem until my Freshman year of college, and I
still have to look up the details to remind myself.) So, the
“simplicity brings clarity” idea hints that RSA is a better
choice.

Fact is, there was only one reason why I revoked my ancient RSA
keys and generated DSA ones in the 1990s. The RSA patent and the strict
licensing of that patent by RSA Data Security, Inc. made it impossible
to implement RSA in Free Software back then. So, when I switched from
proprietary PGP to GPG, my keys wouldn’t import. Indeed, that one RSA
patent alone set back the entire area of Free Software cryptography at least ten years.

So, when I decided this evening that I’d need to generate a new key and
begin promulgating it at key-signing parties sometime before DB41B387
turns ten, I realized I actually have the freedom to choose my
encryption algorithm now! Sadly, it took almost these entire nine years
to get there. Our community did not only have to wait out this
unassailable patent. (RSA is among the most novel and non-obvious ideas
that most computer professionals will ever seen in their lives). Once
the RSA patent finally expired⁰, we had to then slowly but
surely implement and deploy it in cryptographic programs, from
scratch.

I’m still glad that we’re free of the RSA patent, but I fear among the
mountain of “software patents” granted each year, that the
“new RSA” — a perfectly valid, non-obvious and novel
patent that reads on software and fits both the industry’s and patent
examiner’s definition of “high quality” — is waiting
to be discovered and used as a weapon to halt Free Software again. When
I finally type gpg --gen-key (now with
--expert mode!) for the first time in nine years, I hope
I’ll only experience the gladness of being able to generate an RSA key,
and succeed in ignoring the fact that RMS’
old essay about this issue remains a cautionary tale to this very
day. Software patents are a serious long-term threat and must be
eradicated entirely for the sake of software freedom. The biggest threat among them will always be the “valid”, “high quality”
software patents, not the invalid, poor quality ones.

⁰ Technically speaking,
RSA didn’t need to expire. In a seemingly bizarre
move, RSA Data Security, Inc. granted a Free license to the
patent a few weeks before the actual expiration date. To
this day, I believe the same theory I espoused at the time:
their primary goal in doing this was merely to ruin all the
“RSA is Free” parties that had been planned.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/09/gpg-gen-key-decade.html

Today is an interesting anniversary (of sorts) for my cryptographic
infrastructure. Nine years ago today, I generated the 1024 bit DSA key,
DB41B387, that has been my GPG key every day since then. I remember
distinctly that on the 350 MhZ machine I used at the time, it took quite
a while to generate, even though I made sure the entropy pool remained
nice and full by pounding on the keyboard.

The horribleness of the
recent Debian vulnerability meant that I have spent a much time
this year pondering the pedigree my personal cryptographic
infrastructure. Of course, my key was far too old to have been
generated on a Debian-based system that had that particular
vulnerability. However, the issue that really troubled me this
past summer was this:

Some DSA keys may be compromised by only their use. A strong
key (i.e., generated with a ‘good’ OpenSSL) but used locally
on a machine with a ‘bad’ OpenSSL must be considered to be
compromised. This is due to an ‘attack’ on DSA that allows the
secret key to be found if the nonce used in the signature is reused or
known.

Not being particularly hard core on cryptographic knowledge — most of my expertise comes from only one class I took 11 years ago on
Encryption, Compression, and Secure Hashing in graduate school —
I found this alarming and tried my best to do some ancillary reading.
It seems that DSA keys, in many ways, are less than optimal. It seems
(to my mostly uneducated eye) in skimming academic papers that DSA keys
are tougher to deploy right and keep secure, which leads to these sorts
of possible problems.

I’ve resolved to switch entirely to RSA keys. The great thing about
RSA is its simplicity and ease of understanding. I grok factoring and
understand better the complexity situation of the factoring problem
(this time, from the two graduate courses I took on Complexity
Theory, so my comfort is more solid :). I also find it intriguing that
a child can learn how to factor in grade school, yet we can’t teach a
computer to do it efficiently. (By contrast, I didn’t learn the
discrete logarithm problem until my Freshman year of college, and I
still have to look up the details to remind myself.) So, the
“simplicity brings clarity” idea hints that RSA is a better
choice.

Fact is, there was only one reason why I revoked my ancient RSA
keys and generated DSA ones in the 1990s. The RSA patent and the strict
licensing of that patent by RSA Data Security, Inc. made it impossible
to implement RSA in Free Software back then. So, when I switched from
proprietary PGP to GPG, my keys wouldn’t import. Indeed, that one RSA
patent alone set back the entire area of Free Software cryptography at least ten years.

So, when I decided this evening that I’d need to generate a new key and
begin promulgating it at key-signing parties sometime before DB41B387
turns ten, I realized I actually have the freedom to choose my
encryption algorithm now! Sadly, it took almost these entire nine years
to get there. Our community did not only have to wait out this
unassailable patent. (RSA is among the most novel and non-obvious ideas
that most computer professionals will ever seen in their lives). Once
the RSA patent finally expired⁰, we had to then slowly but
surely implement and deploy it in cryptographic programs, from
scratch.

I’m still glad that we’re free of the RSA patent, but I fear among the
mountain of “software patents” granted each year, that the
“new RSA” — a perfectly valid, non-obvious and novel
patent that reads on software and fits both the industry’s and patent
examiner’s definition of “high quality” — is waiting
to be discovered and used as a weapon to halt Free Software again. When
I finally type gpg --gen-key (now with
--expert mode!) for the first time in nine years, I hope
I’ll only experience the gladness of being able to generate an RSA key,
and succeed in ignoring the fact that RMS’
old essay about this issue remains a cautionary tale to this very
day. Software patents are a serious long-term threat and must be
eradicated entirely for the sake of software freedom. The biggest threat among them will always be the “valid”, “high quality”
software patents, not the invalid, poor quality ones.

⁰ Technically speaking,
RSA didn’t need to expire. In a seemingly bizarre
move, RSA Data Security, Inc. granted a Free license to the
patent a few weeks before the actual expiration date. To
this day, I believe the same theory I espoused at the time:
their primary goal in doing this was merely to ruin all the
“RSA is Free” parties that had been planned.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/09/gpg-gen-key-decade.html

Today is an interesting anniversary (of sorts) for my cryptographic
infrastructure. Nine years ago today, I generated the 1024 bit DSA key,
DB41B387, that has been my GPG key every day since then. I remember
distinctly that on the 350 MhZ machine I used at the time, it took quite
a while to generate, even though I made sure the entropy pool remained
nice and full by pounding on the keyboard.

The horribleness of the
recent Debian vulnerability meant that I have spent a much time
this year pondering the pedigree my personal cryptographic
infrastructure. Of course, my key was far too old to have been
generated on a Debian-based system that had that particular
vulnerability. However, the issue that really troubled me this
past summer was this:

Some DSA keys may be compromised by only their use. A strong
key (i.e., generated with a ‘good’ OpenSSL) but used locally
on a machine with a ‘bad’ OpenSSL must be considered to be
compromised. This is due to an ‘attack’ on DSA that allows the
secret key to be found if the nonce used in the signature is reused or
known.

Not being particularly hard core on cryptographic knowledge — most of my expertise comes from only one class I took 11 years ago on
Encryption, Compression, and Secure Hashing in graduate school —
I found this alarming and tried my best to do some ancillary reading.
It seems that DSA keys, in many ways, are less than optimal. It seems
(to my mostly uneducated eye) in skimming academic papers that DSA keys
are tougher to deploy right and keep secure, which leads to these sorts
of possible problems.

I’ve resolved to switch entirely to RSA keys. The great thing about
RSA is its simplicity and ease of understanding. I grok factoring and
understand better the complexity situation of the factoring problem
(this time, from the two graduate courses I took on Complexity
Theory, so my comfort is more solid :). I also find it intriguing that
a child can learn how to factor in grade school, yet we can’t teach a
computer to do it efficiently. (By contrast, I didn’t learn the
discrete logarithm problem until my Freshman year of college, and I
still have to look up the details to remind myself.) So, the
“simplicity brings clarity” idea hints that RSA is a better
choice.

Fact is, there was only one reason why I revoked my ancient RSA
keys and generated DSA ones in the 1990s. The RSA patent and the strict
licensing of that patent by RSA Data Security, Inc. made it impossible
to implement RSA in Free Software back then. So, when I switched from
proprietary PGP to GPG, my keys wouldn’t import. Indeed, that one RSA
patent alone set back the entire area of Free Software cryptography at least ten years.

So, when I decided this evening that I’d need to generate a new key and
begin promulgating it at key-signing parties sometime before DB41B387
turns ten, I realized I actually have the freedom to choose my
encryption algorithm now! Sadly, it took almost these entire nine years
to get there. Our community did not only have to wait out this
unassailable patent. (RSA is among the most novel and non-obvious ideas
that most computer professionals will ever seen in their lives). Once
the RSA patent finally expired⁰, we had to then slowly but
surely implement and deploy it in cryptographic programs, from
scratch.

I’m still glad that we’re free of the RSA patent, but I fear among the
mountain of “software patents” granted each year, that the
“new RSA” — a perfectly valid, non-obvious and novel
patent that reads on software and fits both the industry’s and patent
examiner’s definition of “high quality” — is waiting
to be discovered and used as a weapon to halt Free Software again. When
I finally type gpg --gen-key (now with
--expert mode!) for the first time in nine years, I hope
I’ll only experience the gladness of being able to generate an RSA key,
and succeed in ignoring the fact that RMS’
old essay about this issue remains a cautionary tale to this very
day. Software patents are a serious long-term threat and must be
eradicated entirely for the sake of software freedom. The biggest threat among them will always be the “valid”, “high quality”
software patents, not the invalid, poor quality ones.

⁰ Technically speaking,
RSA didn’t need to expire. In a seemingly bizarre
move, RSA Data Security, Inc. granted a Free license to the
patent a few weeks before the actual expiration date. To
this day, I believe the same theory I espoused at the time:
their primary goal in doing this was merely to ruin all the
“RSA is Free” parties that had been planned.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/04/license-drafting-responsibility.html

I finally set aside some time to
read my
old boss’ open letter responding to criticisms of the FDL process.
I read gladly his discussion of the responsibilities of software freedom
license stewardship.

I’ve been involved with the drafting of a number of FLOSS licenses (and
exceptions to existing licenses). For example, I helped RMS a little
with the initial FDL 1.0 drafting (the license at issue here); I was a
catalyst for the creation of Artistic 2.0 and advised that process; and,
I was
heavily involved with the creation of the AGPL, and somewhat with
the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed
when kibitzed by a user who just downloaded the program and is missing
something obvious, we license drafters are human and often have the
“did this person even read all the stuff we’ve written on
this issue?” knee-jerk response to criticism. However, we all try
to put that aside, and be ready to respond and take seriously any
reasonable criticism. I am glad that RMS has done so here. The entity
that controls future versions of a license for which authors often use
an “or later” term holds great power. As the clichéd
Spiderman saying goes, with great power, comes great
responsibility.

The FSF as a whole, and RMS in particular, have always know this well
and take it very seriously. Indeed, years ago, when I was still at FSF,
RMS and I
wrote an
essay together on a closely related
issue. This
recent response on FDL reiterates some of those points, but with a
real-world example explaining the decision making process regarding the
reasonable exercise of that power to, in turn, grant rights and freedoms
rather than take them away.

The key quote from his letter that stands out to me is: our
commitment is that our changes to a license will stick to the spirit of
that license, and will uphold the purposes for which we wrote it.
This point is fundamental. As FLOSS license drafters, we must always, as
RMS says, abide by the highest ethical standards to uphold the
spirit that spurred the creation of these licenses.

Far from being annoyed, I’m grateful for those who assume the worst of
intentions and demand that we justify ourselves. For my part, I try to
answer every question I get at conferences and in email about licensing
policy as best I can with this point in mind. We in the non-profit
licensing sector of the FLOSS world have a duty to the community of FLOSS
users and programmers to defend their software freedom. I try to make
every decision, on licensing policy (or, indeed, any issue) with that goal
in mind. I know that my colleagues at the FSF and at the many other
not-for-profit organizations always do the same, too.