Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2017/02/13/conservancy.html

There are a lot of problems in our society, and particularly in the USA,
right now, and plenty of charities who need our support. The reason I
continue to focus my work on software freedom is simply because there are
so few focused on the moral and ethical issues of computing. Open Source
has reached its pinnacle as an industry fad, and with it, a watered-down
message: “having some of the source code for some of your systems
some of the time is so great, why would you need anything more?”.
Universal software freedom is
however further
from reality than it was even a few years ago. At least a few of us,
in my view, must focus on that cause.

I did not post many blog posts about this in 2016. There was a reason for
that — more than any other year, work demands at Conservancy have
been constant and unrelenting. I enjoy my work, so I don’t mind, but
blogging becomes low priority when there is a constant backlog of urgent
work to support Conservancy’s mission and our member projects. It’s not
just Conservancy’s mission, of course, it’s my personal one as well.

For our 2016 fundraiser,
I wrote last
year a blog post entitled “Do You Like What I Do For a
Living?”. Last year, so many of you responded, that it not only
made it possible for me to continue that work for one more year, but we
were able to add our colleague Brett Smith to our staff, which brought
Conservancy to four full-time staff for the first time. We added a few
member projects (and are moving that queue to add more in 2017), and sure
enough — the new work plus the backlog of work waiting for another
staffer filled Brett’s queue just like my, Karen’s and Tony’s was already
filled.

The challenge now is sustaining this staffing level. Many of you came to
our aid last year because we were on the brink of needing to reduce our
efforts (and staffing) at Conservancy. Thanks to your overwhelming
response, we not only endured, but we were able to add one additional
person. As expected, though, needs of our projects increased throughout
the year, and we again — all four of us full-time staff — must
work to our limits to meet the needs of our projects.

Charitable donations are a voluntary activity, and as such they have a
special place in our society and culture. I’ve talked a lot about how
Conservancy’s Supporters give us a mandate to carry out our work. Those of
you that chose to renew your Supporter donations or become new Supporters
enable us to focus our full-time efforts on the work of Conservancy.

On the signup and renewal
page, you can read about some of our accomplishments in the last year
(including my
recent keynote at FOSDEM, an excerpt of which is included here). Our
work does not follow fads, and it’s not particularly glamorous, so only
dedicated Supporters like you understand its value. We don’t expect to
get large grants to meet the unique needs of each of our member projects,
and we certainly don’t expect large companies to provide very much
funding unless we cede control of the organization to their requests (as
trade associations do). Even our most popular program, Outreachy, is
attacked by a small group of people who don’t want to see the status quo
of privileged male domination of Open Source and Free Software
disrupted.

Supporter contributions are what make Conservancy possible. A year ago,
you helped us build Conservancy as a donor-funded organization and
stabilize our funding base. I now must ask that you make an annual
commitment to renewal — either
by renewing your contribution
now or becoming
a monthly supporter, or, if you’re just learning about my work at
Conservancy from this blog
post, reading up
on us
and becoming a new
Supporter.

Years ago, when I was still only a part-time volunteer at Conservancy,
someone who disliked our work told me that I had “invented a job of
running Conservancy”. He meant it as an insult, but I take it as a
compliment with pride. In fact, between me and my colleague (and our
Executive Director) Karen Sandler, we’ve “invented” a total of
four full-time jobs and one part-time one to advance software freedom. You
helped us do that with your donations. If you donate again today, your
donation will be matched to make the funds go further.

Many have told me this year that they are driven to give to other
excellent charities that fight racism, work for civil and immigration
rights, and other causes that seem particularly urgent right now. As long
as there is racism, sexism, murder, starvation, and governmental oppression
in the world, I cannot argue that software freedom should be made a
priority above all of those issues. However, even if everyone in our
society focused on a single, solitary cause that we agreed was the top
priority, it’s unlikely we could make quicker progress. Meanwhile, if we
all single-mindedly ignore less urgent issues, they will, in time, become so
urgent they’ll be insurmountable by the time we focus on them.

Industrialized nations have moved almost fully to computer automation for
most every daily task. If you question this fact, try to do your job for a
day without using any software at all, or anyone using software on your
behalf, and you’ll probably find it impossible. Then, try to do your job
using only Free Software for a day, and you’ll find, as I have, that tasks
that should take only a few minutes take hours when you avoid proprietary
software, and some are just impossible. There are very few organizations
that are considering the long-term implications of this slowly growing
problem and making plans to build the foundations of a society that doesn’t
have that problem. Conservancy is one of those few, so I hope you’ll
realize that long-term value of our lifelong work to defend and expand
software freedom and donate.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2017/02/13/conservancy.html

There are a lot of problems in our society, and particularly in the USA,
right now, and plenty of charities who need our support. The reason I
continue to focus my work on software freedom is simply because there are
so few focused on the moral and ethical issues of computing. Open Source
has reached its pinnacle as an industry fad, and with it, a watered-down
message: “having some of the source code for some of your systems
some of the time is so great, why would you need anything more?”.
Universal software freedom is
however further
from reality than it was even a few years ago. At least a few of us,
in my view, must focus on that cause.

I did not post many blog posts about this in 2016. There was a reason for
that — more than any other year, work demands at Conservancy have
been constant and unrelenting. I enjoy my work, so I don’t mind, but
blogging becomes low priority when there is a constant backlog of urgent
work to support Conservancy’s mission and our member projects. It’s not
just Conservancy’s mission, of course, it’s my personal one as well.

For our 2016 fundraiser,
I wrote last
year a blog post entitled “Do You Like What I Do For a
Living?”. Last year, so many of you responded, that it not only
made it possible for me to continue that work for one more year, but we
were able to add our colleague Brett Smith to our staff, which brought
Conservancy to four full-time staff for the first time. We added a few
member projects (and are moving that queue to add more in 2017), and sure
enough — the new work plus the backlog of work waiting for another
staffer filled Brett’s queue just like my, Karen’s and Tony’s was already
filled.

The challenge now is sustaining this staffing level. Many of you came to
our aid last year because we were on the brink of needing to reduce our
efforts (and staffing) at Conservancy. Thanks to your overwhelming
response, we not only endured, but we were able to add one additional
person. As expected, though, needs of our projects increased throughout
the year, and we again — all four of us full-time staff — must
work to our limits to meet the needs of our projects.

Charitable donations are a voluntary activity, and as such they have a
special place in our society and culture. I’ve talked a lot about how
Conservancy’s Supporters give us a mandate to carry out our work. Those of
you that chose to renew your Supporter donations or become new Supporters
enable us to focus our full-time efforts on the work of Conservancy.

On the signup and renewal
page, you can read about some of our accomplishments in the last year
(including my
recent keynote at FOSDEM, an excerpt of which is included here). Our
work does not follow fads, and it’s not particularly glamorous, so only
dedicated Supporters like you understand its value. We don’t expect to
get large grants to meet the unique needs of each of our member projects,
and we certainly don’t expect large companies to provide very much
funding unless we cede control of the organization to their requests (as
trade associations do). Even our most popular program, Outreachy, is
attacked by a small group of people who don’t want to see the status quo
of privileged male domination of Open Source and Free Software
disrupted.

Supporter contributions are what make Conservancy possible. A year ago,
you helped us build Conservancy as a donor-funded organization and
stabilize our funding base. I now must ask that you make an annual
commitment to renewal — either
by renewing your contribution
now or becoming
a monthly supporter, or, if you’re just learning about my work at
Conservancy from this blog
post, reading up
on us
and becoming a new
Supporter.

Years ago, when I was still only a part-time volunteer at Conservancy,
someone who disliked our work told me that I had “invented a job of
running Conservancy”. He meant it as an insult, but I take it as a
compliment with pride. In fact, between me and my colleague (and our
Executive Director) Karen Sandler, we’ve “invented” a total of
four full-time jobs and one part-time one to advance software freedom. You
helped us do that with your donations. If you donate again today, your
donation will be matched to make the funds go further.

Many have told me this year that they are driven to give to other
excellent charities that fight racism, work for civil and immigration
rights, and other causes that seem particularly urgent right now. As long
as there is racism, sexism, murder, starvation, and governmental oppression
in the world, I cannot argue that software freedom should be made a
priority above all of those issues. However, even if everyone in our
society focused on a single, solitary cause that we agreed was the top
priority, it’s unlikely we could make quicker progress. Meanwhile, if we
all single-mindedly ignore less urgent issues, they will, in time, become so
urgent they’ll be insurmountable by the time we focus on them.

Industrialized nations have moved almost fully to computer automation for
most every daily task. If you question this fact, try to do your job for a
day without using any software at all, or anyone using software on your
behalf, and you’ll probably find it impossible. Then, try to do your job
using only Free Software for a day, and you’ll find, as I have, that tasks
that should take only a few minutes take hours when you avoid proprietary
software, and some are just impossible. There are very few organizations
that are considering the long-term implications of this slowly growing
problem and making plans to build the foundations of a society that doesn’t
have that problem. Conservancy is one of those few, so I hope you’ll
realize that long-term value of our lifelong work to defend and expand
software freedom and donate.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
Linux developer community about Conservancy’s
GPL Compliance Project for
Linux Developers.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
and leader of gpl-violations.org,
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage? I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
about the remainder? From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.