Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

sec.stanev.org прераждане

Post Syndicated from RealEnder original https://alex.stanev.org/blog/?p=283

Преди десетина години създадох sec.stanev.org като място, където да публикувам проблемите в сигурността, които откривам в различни приложения. Когато смених работата си, първите ми задължения в новата компания бяха да подобря сигурността на разработваните системи и електронни услуги. Това на практика спря всякаква активност в sec.stanev.org, тъй като откритите проблеми трябваше да си останат под покрива (NDA), а извънкласно почти не ми се занимаваше, след като цял ден съм се взирал в странен код и съм писал patches на поразия. Доста интересни неща се погребаха по този начин, но през годините винаги ми е трепвало, когато бъг, на който съм попаднал преди време изскочи в пространството.

От спортна злоба реших да препипам сайта и когато ми прищрака ще пускам по нещо. Днес пуснах advisory, по проблем, за който разказах на последния OpenFest. Там имаше интересни коментари и се събраха още весели идеи по темата.

Ще ми е интересно да коментирате какво ново искате да видите на сайта.

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

Should a Power-User Key Mapping Change Be This Difficult?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/05/31/x.html

It’s been some time since X made me hate computing, but it happened
again today (well, yesterday into the early hours of today,
actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I
was at work, but it was actually a holiday in the USA, and I figured it
would be a good time to do some sysadmin work instead of my usual
work.

I admittedly had some things to fix that were my fault: I had backports
and other mess installed, but upon removing, the upgrade itself was
more-or-less smooth. I faced only a minor problem with my MD device for
/boot not starting properly, but the upgrade warned me that I needed to
switch to properly using the UUIDs for my RAID arrays, and once I
corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys
weren’t working. BTW, I separate Alt from Meta, making my actual Alt key
into a meta key, while my lower control is set to an Alt (ala Mod2), since
I throw away caps lock and make it a control. (This is for when I’m on
the laptop keyboard rather than the HHKB.)

I’ve used the same xmodmap for two decades to get this done:

        keycode 22 = BackSpace
        
        clear Mod1
        clear Mod2
        clear Lock
        clear Control
        
        keycode 66  = Control_L
        
        keycode 64 = Meta_L
        keycode 113 = Meta_R
        keycode 37 = Alt_L
        keycode 109 = Alt_R
        
        add Control = Control_L
        
        add Mod1 = Meta_L
        add Mod1 = Meta_R
        
        add Mod2 = Alt_L
        add Mod2 = Alt_R
        

This just “doesn’t work” in squeeze (or presumably any Xorg
7.5 system). Instead, it just gives this error message:

        X Error of failed request:  BadValue (integer parameter out of range for operation)
          Major opcode of failed request:  118 (X_SetModifierMapping)
          Value in failed request:  0x17
          Serial number of failed request:  21
          Current serial number in output stream:  21
        

… and while my Control key ends up fine, it leaves me with no Mod1
nor Mod2 key.

There appear to be at least two Debian bugs
(564327
and 432011), which were
against squeeze before it was released. In retrospect, I sure wish
they’d have been release-critical!. (There’s also
an Ubuntu
bug
, which of course just punts to the upstream Debian bug.) There
are also two further upstream bugs at freedeskop
(20145
and
11822),
although Daniel
Stone
thinks the main
problem might be fixed upstream
.

I gather that many people “in the know” believe xmodmap to
be deprecated, and we all should have switched to xkb years ago. I even
got snarky comments to that
effect
. (Update🙂 However, after I made
this first post, quite angry after 8 hours of just trying to make my Alt
key DTRT, I was elated to see Daniel Stone
indicate that xmodmap should
be backwards compatible
. It’s always true that almost every time I
get pissed off about some Free Software not working, a developer often
shows up and tells me they want to fix it. This is in some ways just as
valuable as the thing being fixed: knowing that the developer doesn’t
want the bug to be there — it means it’ll be fixed eventually and
only patience is required.

However, the bigger problem really is that xkb appears to lack good
documentation. If any exists, I can’t find
it. madduck did this
useful blog post
(and,
later, vinc17 showed me
some docs he was working on too
). These are basically the only
things I could find that were real help on the issue, and they were
sparse. I was able to learn, after hours, that this should be the rough
equivalent to my old modmap:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            replace key <CAPS>  {  [ Control_L, Control_L ] };
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L, Meta_R };
            key <LCTL> { [ Alt_L ] };
            modifier_map Mod2 { Alt_L };
        };
        

But, you can’t just load that with a program! No, it must be placed in
a file called /path/symbols/bkuhn, which it is then loaded with an
incantation like this:

        xkb_keymap {
                xkb_keycodes  { include "evdev+aliases(qwerty)" };
                xkb_types     { include "complete"      };
                xkb_compat    { include "complete"      };
                xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                xkb_geometry  { include "pc(pc105)"     };
        };
        

…which, in turn, requires to be fed into: xkbcomp -I/path
- $DISPLAY
as stdin. Oh, did I mention you have to get the
majority of that stuff above by running setxkbmap -print,
then modify it to add the bkuhn(thinkpad) part? I’m
impressed that madduck figured this all out. I mean, I know xmodmap was
arcane incantations and all, but this is supposed to be clearer
and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn’t work. I tried every
incantation I could think of, but I couldn’t get it to think about Alt and
Meta as separate Mod2 and Mod1 keys. I think it’s actually a bug, because
weird things happened when I added lines like:

            modifier_map Mod5 { <META> };
        

Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2
was then picked up correctly (magically!), but then both LCTL and LALT
acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate
to get back to my 20 years of keystroke memory to try to document what was
going on well enough for a coherent bug report. (Remember, I was doing
all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF
DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could
force the literal LCTL key to be a Mod3, hopefully allowing Emacs to
again see my usual Mod1 Meta expectations for LALT. So, I saw what some
of the code in /usr/share/X11/xkb/symbols/altwin did to
handle Mod3, and I got this working (although it required a sawfish
change to expect Mod3 instead of Mod2, of course, but that part was 5
seconds of search and replace). Here’s what finally worked as contents
of /path/symbols/bkuhn:

        partial modifier_keys
        xkb_symbols "thinkpad" {
            modifier_map  Control { <CAPS> };
            replace key <LALT>  {  [ Meta_L ] };
            modifier_map Mod1   { Meta_L };
            key <LCTL> { type[Group1] = "ONE_LEVEL",
                         symbols[Group1] = [ Super_L ] };
            modifier_map Mod3 { Super_L };
        };
        

So, is all this really less arcane than xmodmap? Was the eight hours
of my life spent learning xkb was somehow worth it, because now I know a
better tool than xmodmap? I realize I’m a power user, but I’m not
convinced that it should be this hard even for power users. I felt
reminiscent of days when I had to
use Eric
Raymond’s mode timings howto to get X working
. That was actually
easier than this!

Even though spot claimed
this is somehow Debian’s fault
, I don’t believe him. I bet I
would run into the same problem on any system using Xorg 7.5. There
are clearly known bugs in xmodmap, and I think there is probably a
subtle bug I uncovered that exist xkbd, but I am not sure I can
coherently report it without revisiting this horrible computing
evening again. Clearly, that first thing I tried should have not made
two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you’re looking for me online tomorrow early, you hopefully know
where I am. I’m going to bed two hours before my usual waketime. Ugh.
(Update: tekk
later typo’ed xmodmap as ’xmodnap‘ on identi.ca
.
Quite fitting; after working on that all night, I surely needed an xmodnap!

Update on 2013-04-03: I want to note that the X11 and now
Wayland developer
named Daniel
Stone
took an interest in this bug and actually followed up with me two
years later giving me a report. It is apparently really hard to fix
without a lot of effort, and I’ve switched to xkb (which I think is even
more arcane), but mostly works, except when I’m in Xnest. But my main
point is that Daniel stuck with the problem and while he didn’t get
resolution, he kept me posted. That’s a dedicated Free Software developer;
I’m just a random user, after all!

The collective thoughts of the interwebz