Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/15/launchpad-agplv3.html

Last week, I asked Karl
Fogel, Canonical’s newly hired Launchpad Ombudsman, if Launchpad
will use
the AGPLv3.
His eyes said “yes” but his words were something like:
Canonical hasn’t announced the license choice yet. I was excited
to learn this morning from him
that Launchpad’s
license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application
that we designed the AGPLv3 for, and Launchpad is rapidly becoming a
standard in the next generation of Free Software project hosting. Over
the last year, I’ve felt much trepidation that Launchpad would be
“another SourceForge”: that great irony of a proprietary
platform becoming the canonical method for Free Software project
hosting. It seems now the canonical and the Canonical method
for hosting will be Launchpad, and it will respect the freedom of
network users of the service.

Given
that they’d already announced plans to liberate Launchpad, it’s not
really surprising that Canonical has selected the AGPLv3. I would guess
their primary worry about releasing the source was ensuring that
competitors don’t sprout up and fail to share their improvements back
with the community of users. AGPLv3 is specifically designed for this
situation.

I’m glad we’ve made a license that is getting adoption by top-tier
Free Software projects like this one. Critics keep saying that AGPLv3
is a marginal license of limited interest. I hope this license choice
by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are
helping make this happen.

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.