Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/14/qt-lgpl.html

The decision between the GPL or LGPL for a library is a complex one,
particularly when that library solves a new problem or an old problem in
a new way. TrollTech faced this decision for the Qt library, and Nokia
(who acquired Trolltech last year) has now reconsidered the question and
come to a different conclusion. Having followed this situation since
even before Qt was GPL’d, I was glad that we have successfully
encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this
subject,
entitled Why
you shouldn’t use the Lesser GPL for your next library. A
few times a year, I find myself rereading that essay because I believe
it puts forward some good points to think about when making this
decision.

Nevertheless, there is a strong case for the LGPL in many situations.
Sometimes, pure copyleft negatively impacts the goal of maximal software
freedom. The canonical example, of course, is the GNU C Library (which
was probably the first program ever LGPL’d).

Glibc was LGPL’d, in part, because it was unlikely at the time that
anyone would adopt a fully FaiF (Free as in Freedom) operating system
that didn’t allow any proprietary applications. Almost every program on
a Unix-like system combines with the C library, and if it were GPL’d,
all applications would be covered by the GPL. Users of the system
would have freedom, but encouraging the switch would be painful because
they’d have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite
some time, as our community slowly replaced each application with
freedom-respecting implementations. In the meantime, better that
proprietary software users have a FaiF C library and a FaiF operating
system to use (even with proprietary applications) while work
continued.

We now face a similar situation in the mobile device space. Most
mobile devices used today are locked down, top to bottom. It makes
sense to implement the approach we know works from our two decades of
experience — liberate the operating system first and the
applications will slowly follow.

This argument informs the decision about Qt’s licensing. Qt and its
derivatives are widely used as graphics toolkits in mobile devices.
Until now, Qt was licensed under GPL (and before that various semi-Free
licenses). Not only did the GPL create a “best is the enemy of
the good” situation, but those companies that rejected the GPL
could simply license a proprietary copy from TrollTech, which further
ghettoized the GPL’d versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL
yields an important side benefit. While the proprietary relicensing
business is a common and legitimate business model to fund further
development, it also has some negative social side effects. The
codebase often lives in a silo, discouraging contributions from those
who don’t receive funding from the company who controls the canonical
upstream.

A change to LGPL sends a loud and clear message — the proprietary
relicensing business for Qt is over. Developers who have previously
rejected Qt because it was not community-developed might want to
reconsider that position in light of this news. We don’t know yet how
the new Qt community will be structured, but it’s now clear that Nokia,
Qt’s new copyright holder, no longer has a vested interest in
proprietary relicensing. The opportunity for a true software freedom
community around Qt’s code base has maximum potential at this moment. A
GUI programmer I am not; but I hope those who are will take a look and
see how to create the software freedom development community that Qt
needs.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/24/capra-free-software.html

I suppose it’s time for me to confess. For a regular humbug who was
actually memory-leak-hunting libxml2 at the office until 21:30 on December
24th, I’m still quite a sucker for Frank Capra movies. Most people
haven’t seen any of them except It’s a Wonderful Life. Like
a lot of people, I see that film annually one way or the other, too.

Fifteen years ago, I wrote a college paper on Capra’s vision and
worldview; it’s not surprising someone who has devoted his life to Free
Software might find resonance in it. Capra’s core theme is simple (some
even call it simplistic): An honest, hard-working idealist will always
overcome if he never loses sight of community and simply refuses any
temptation of corruption.

I don’t miss the opportunity to watch It’s a Wonderful
Life when it inevitably airs each year. (Meet John
Doe sometimes can be found as well around this time of year
— catch that one too if you can.) I usually perceive something
new in each viewing.

(There are It’s a Wonderful Life spoilers below here; if
you actually haven’t seen it, stop here.)

This year, what jumped out at me was the second of the three key
speeches that George Bailey gives in the film. This occurs during the
bank run, when Building and Loan investors are going to give up on the
organization and sell their shares immediately at half their worth. I
quote the speech in its entirety:

You’re thinking of this place all wrong. As if I had the money back in a
safe. The money’s not here. Your money’s in Joe’s house; that’s right
next to yours. And in the Kennedy house, and Mrs. Macklin’s house, and a
hundred others. Why, you’re lending them the money to build, and then,
they’re going to pay it back to you as best they can. Now what are you
going to do? Foreclose on them?

[Shareholders decide to go to Potter and
sell. Bailey stops the mob.]

Now wait; now listen. Now listen to me. I
beg of you not to do this thing. If Potter gets hold of this Building and
Loan there’ll never be another decent house built in this town. He’s
already got charge of the bank. He’s got the bus line. He got the
department stores. And now he’s after us. Why?

Well, it’s very simple. Because we’re cutting in on his business,
that’s why, and because he wants to keep you living in his slums and
paying the kind of rent he decides. Joe, you had one of those Potter
houses, didn’t you? Well, have you forgotten? Have you forgotten what he
charged you for that broken-down shack?

Ed, you know! You remember last year when things weren’t going so well,
and you couldn’t make your payments? You didn’t lose your house, did you?
Do you think Potter would have let you keep it?

Can’t you understand what’s happening here? Don’t you see what’s
happening? Potter isn’t selling. Potter’s buying! And why? Because
we’re panicking and he’s not. That’s why. He’s picking up some bargains.
Now, we can get through this thing all right. We’ve got to stick
together, though. We’ve got to have faith in each other.

Perhaps this quote jumped out on me because all the bank run jokes made
this year. However, that wasn’t the first thing that came to mind.
Instead, I thought immediately of Microsoft’s presence at OSCON this
year and the launch of their campaign to pretend they haven’t spent the
last ten years trying destroy all of Free Software and Open Source.

In the film, Potter eventually convinces George to come by his office
for a meeting, offers him some fine cigars, and tells him
that George’s ship has come in because Potter is ready to give
him a high paying job. George worries that the Building and Loan will fail
if he takes the job. Potter’s (non)response is: Confounded, man, are
you afraid of success!?

It’s going to get more tempting to make deals with Microsoft. We’re
going to feel like their sudden (seemingly) positive interest in us
— like Potter’s sudden interest in George — is something to
make us proud. It is, actually, but not for the obvious reason. We’re
finally a viable threat to the future of proprietary software. They’ve
reached the stage where they know they can’t kill us. They are going to
try to buy us, try to corrupt us, try to do anything they can to
convince us to give up our principles just to make our software a little
better or a little more successful. But we can do those things anyway, on our own, in the fullness of time.

Never forget why they are making the offer. Microsoft is unique
among proprietary software companies: they are the only ones who have
actively tried to kill Open Source and Free Software. It’s not
often someone wants to be your friend after trying to kill you for ten
years, but such change is cause for suspicion. George was smart enough
to see this and storm out of Potter’s office, saying: You sit around here and spin your little webs and think the whole world revolves
around you and your money! Well, it doesn’t, Mr. Potter!. To
Microsoft, I’d say: and that goes for you, too!