Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/15/gpl-consistency.html

Most of you are aware
from one of my
previous posts that It’s a Wonderful Life! is my
favorite film. Recently, I encountered something in the software
freedom community that reminded me of yet another quote from the
flim:

GEORGE:

Look, uh … I think maybe you better not mention getting your wings around here.

CLARENCE:

Why? Don’t they believe in angels?

GEORGE:

I… yeah, they believe in them…

CLARENCE:

Ohhh … Why should they be surprised when
they see one?

Obviously, I don’t believe in angels myself. But, Clarence’s
(admittedly naïve) logic is actually impeccable: Either you
believe in angels or you don’t. If you believe in angels, then you
shouldn’t be surprised to (at least occasionally) see one.

This film quote came to my mind in reference to a concept in GPL
enforcement. Many people give lip service to the idea that the GPL, and
copyleft generally, is a unique force that democratizes software and
ensures that FLOSS cannot be exploited by proprietary software
interests. Many of these same people, though, oppose GPL enforcement
when companies exploit GPL’d code and don’t give the source code and
take away users’ rights to modify and share that software.

I’ve
admitted that the copyleft is merely a strategy to achieve maximal
software freedom. There are other strategies too, such as the Apache
community process. The Apache Software Foundation releases software
under a permissive non-copyleft license, but then negotiates with
companies to convince them to contribute to the code base publicly.
For some projects, that strategy has worked well, and I respect it
greatly.

Some (although not all) people in non-copyleft FLOSS communities (like
the Apache community) are against GPL enforcement. I disagree with
them, but their position is logically consistent. Such folks don’t
agree with us (copyleft-supporting folks) that a license should be used
as a mechanism to guarantee that all published and deployed improved
versions of the software are released in software freedom. It’s not
that those other folks don’t prefer FLOSS; they simply prefer a
non-legally binding social pressure to encourage software sharing rather
than a strategy with legal backup. I prefer a strategy with legal
strength, but I still respect non-copyleft folks who don’t support that.
They take a logically consistent and reasonable approach.

However, it’s ultimately hypocritical to claim support for a copyleft
structure but oppose GPL enforcement. If you believe the license should
have a legal requirement that ensures software is always distributed in
software freedom, then why would you be surprised — or, even
worse, angry — that a copyright holder would seek to uphold users’
rights when that license is violated?

There is great value in having multiple simultaneous strategies ongoing
to achieve important goals. Universal software freedom is my most
important goal, and I expect to spend nearly all of my life focused on
achieving it for all published and deployed software in the world.
However, I don’t expect nor even want everyone else to single-minded-ly
support my exact same strategies in all cases. The diversity of the
software freedom community makes it more likely that we’ll succeed if we
avoid single point of failure on any particular plan, and I support that
diversity.

However, I also think it’s reasonable to expect logically consistent
positions. A copyleft license is effectively indistinguishable from the
Apache license if copyleft is never enforced when violations occur.
Condemning
community-oriented⁰ GPL
enforcement (that seeks primarily to get the code released) while also
claiming to support the idea of copyleft is a logically inconsistent and
self-contradictory position. It’s unfortunate that so many people hold
this contradictory position.

⁰There
are certain types of GPL enforcement that are not consistent with the goal
of universal software freedom. For example, some
so-called “Open
Core” companies are well known for releasing their (solely)
copyrighted code under GPL, and then using GPL enforcement as a mechanism
to pressure users to take a proprietary license. GPL enforcement is only
acceptable in my view if its primary goal is to have all code released
under GPL. Such enforcement must never compromise about one point: that
compliance with the GPL is a non-negotiable term of settling the
enforcement action. If the enforcer is willing to sell out the rights
that users’ have to source code, then even I would condemn, as I have
previously, such GPL enforcement as bad for the software freedom
community. For this reason, in all GPL enforcement that I engage in, I
make it a term of my participation that compliance with the terms of the
GPL for the code in question be a non-negotiable requirement.

Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/ingratitude/

Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/potion/

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory⁰. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography¹. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

⁰Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

¹ I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).