Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/16/tomtom-microsoft.html

There has been a lot of press coverage about the Microsoft/TomTom
settlement. Unfortunately, so far, I have seen no one speak directly
about the dangers that this deal could pose to software freedom, and
what our community should consider in its wake. Karen and I discussed
some of these
details on
our podcast, but I thought it would be useful to have a blog post
about this issue as well.

Most settlement agreements are sealed. This means that we won’t ever
actually know what TomTom agreed to and whether or not it violates
GPLv2. The violation, if one exists, would likely be of GPLv2’s §
7. The problem has always been that it’s difficult to actually witness
a v2§7 violation occurring (due in large part to less than perfect
wording of that section). To find a violation v2§7, you have to
discover that there were conditions imposed on [TomTom] … that
contradict the conditions of [GPLv2]. So, we won’t actually know if
this agreement violates GPLv2 unless we read the agreement itself, or if
we observe some behavior by Microsoft or TomTom that shows that the
agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For
TomTom to have agreed to something GPLv2-compliant with Microsoft, the
agreement would have needed to either (a) not grant a patent license at
all (perhaps, for example, Microsoft conceded in the sealed agreement
that the patents aren’t actually enforceable on the GPLv2’d components),
or (b) give a patent license that was royalty-free and permitted all
GPLv2-protected activities by all recipients of patent-practicing
GPLv2’d code from TomTom, or downstream from TomTom.

It’s certainly possible Microsoft either capitulated regarding the
unenforceability (or irrelevancy) of its patents on the GPLv2’d software
in question, or granted some sort of license. We won’t know directly
without seeing the agreement, or by observing a later action by
Microsoft. If, for example, Microsoft later is observed enforcing the
FAT patent against a Linux distributor, one might successfully argue
that the user must have the right to practice those
Microsoft patents in the GPLv2 code, because otherwise, how was TomTom
able to distribute under GPLv2? (Note, BTW, that any
redistributor of Linux could make themselves downstream from TomTom,
since TomTom distributes source on their website.) If no such
permission existed, TomTom would then be caught in a violation —
at least in my (perhaps minority) reading of GPLv2.⁰

Many have argued that GPLv2 § 7 isn’t worded well enough to
verify this line of thinking. I and a few other key GPL thinkers
disagree, mainly because this reading is clearly the intent of GPLv2
when you read the Preamble. But, there are multiple interpretations of
GPLv2’s wording on this issue, and, the wording was written before the
drafters really knew exactly how patents would be used to hurt Free
Software. We’ll thus probably never really have complete certainty that
such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like
it whose existence is not public, because lawsuits aren’t involved)
almost surely plays into this interpretation ambiguity. Microsoft
likely convinced TomTom that the deal is GPLv2-compliant, and that’s why
there are so many statements in the press opining about its likely GPLv2
compliance. I, Jeremy Allison, and others might be in the minority in
our belief of the strength of GPLv2 § 7, but no one can disagree
with the intent of the section, as stated in the Preamble. Microsoft is
manipulating the interpretation disagreements to convince smaller
companies like Novell, TomTom, and probably others into believing that
these complicated patent licensing deals and/or covenants are
GPLv2-compliant. Since most of them are about the kernel named Linux,
and the Linux copyright holders are the only ones with power to enforce,
Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the
situation. Therefore, this is a great moment in our community to
reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal,
considered carefully how to address these sorts of agreements.
Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

A patent license is “discriminatory” if it does not include
within the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is in
the business of distributing software, under which you make payment to the
third party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who would
receive the covered work from you, a discriminatory patent license (a) in
connection with copies of the covered work conveyed by you (or copies made
from those copies), or (b) primarily for and in connection with specific
products or compilations that contain the covered work, unless you entered
into that arrangement, or that patent license was granted, prior to 28
March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those
in the second paragraph, would clearly and unequivocally prohibit TomTom
from entering into any arrangement with Microsoft that doesn’t grant a
license to any Microsoft patent that reads on Linux. Indeed, even what
has been publicly said about this agreement seems to indicate strongly
that this deal would violate GPLv3. While the Novell/Microsoft deal was
grandfathered in (via the date above), this new agreement is not. Yet,
the most frustrating aspect of the press coverage of this deal is that
few have taken the opportunity to advocate for GPLv3 adoption by more
projects. I hope now that we’re a few weeks out from the coverage,
project leaders will begin again to consider adding this additional
patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should
explain a bit why special patent licensing deals like this are bad for
software freedom; it’s not completely obvious. To do so, we can look
specifically at what TomTom and Microsoft said in the press coverage of
their deal: The agreement protects TomTom’s customers under the
patents …, the companies said
(Microsoft,
TomTom Settle Patent Dispute, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort
of “patent protection” to TomTom customers,
and presumably no one else. This means that if someone buys a
GNU/Linux-based TomTom product, they have greater protection from
Microsoft’s patents than if they don’t. It creates two unequal classes of
users: those who pay TomTom and those who don’t. The ones who don’t pay
TomTom will have to worry if they will be the next ones sued or attacked
in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is
precisely what all versions of the GPL seek to prevent. This is why the
Preamble of GPLv2 said: any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a
free program will individually obtain patent licenses, in effect making
the program proprietary.

Further to this point, in
the Rationale
Document for the Third Discussion Draft of GPLv3, a similar
argument is given in more detail:

The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to the
extent that users feel compelled, by the threat of the patent, to get
their copies in this way. So far, the Microsoft/Novell deal does not seem
to have had this result, or at least not very much: users do not seem to
be choosing Novell for this reason. But we cannot take for granted that
such threats will always fail to harm the community. We take the threat
seriously, and we have decided to act to block such threats, and to reduce
their potential to do harm. Such deals also offer patent holders a crack
through which to split the community. Offering commercial users the chance
to buy limited promises of patent safety in effect invites each of them to
make a separate peace with patent aggressors, and abandon the rest of our
community to its fate.

It’s true that one can blissfully use, redistribute, sell and modify
some patent-covered software for years without ever facing a patent
enforcement action. But, particularly in situations where known patents
have been asserted, those without a patent license often live in fear of
copying, modifying and sharing code that exercises the teachings of the
patent. We saw this throughout the 1990s with RSA, and today most
commonly with audio and video codecs. Microsoft and other anti-Free
Software companies have enough patents to attack if we let them. The
first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3
with the improved patent provisions, and (b) condemning GPLv2-only deals
that solve a patent problem for some users but leave the rest out in the
cold, and (c) pointing out that the purported certainty that such deals
are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under
GPLv2 has probably been underestimated, we cannot overestimate the
additional protection that GPLv3 gives us in this regard. Microsoft
clearly knows that the GPLv3 terms will kill their patent aggression
business model, and have therefore focused their attacks on
GPLv2-licensed code. Shouldn’t we start to flank them by making less
GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom,
as a company, is not necessarily an ally of software freedom. They are
like most for-profit companies; they use FLOSS when it is convenient for
them, and give back when the licenses obligate them to do so, or when it
behooves them in some way. As a for-profit company, they made this deal
to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their
products was done legitimately (that
is, once
their GPLv2 non-compliance was corrected by Harald Welte in 2004).
However, I do not think we should look upon TomTom as a particularly
helpful member of the community. Indeed, most of the patents that
Microsoft asserted against TomTom were on their proprietary components,
not their FLOSS ones. Thus, most of this dispute was a proprietary
software company arguing with another proprietary software company over
patents that read on proprietary software. Our community should tell
TomTom that if they want to join and support the FLOSS world, they
should release their software under a FLOSS license — including
software that they aren’t obligated to do so by the licenses. Wouldn’t it be quite interesting if TomTom’s mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom’s patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn’t they allow us to at least practice the teachings of their patents in GPL’d software?

⁰Update:
Andrew Tridgell pointed out that my verb tenses in my hypothetical example
made the text sound more broadly worded than I intended. I’ve thus
corrected the text in the hypothetical example to be clearer. Thanks for
the clarification, Tridge!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/16/tomtom-microsoft.html

There has been a lot of press coverage about the Microsoft/TomTom
settlement. Unfortunately, so far, I have seen no one speak directly
about the dangers that this deal could pose to software freedom, and
what our community should consider in its wake. Karen and I discussed
some of these
details on
our podcast, but I thought it would be useful to have a blog post
about this issue as well.

Most settlement agreements are sealed. This means that we won’t ever
actually know what TomTom agreed to and whether or not it violates
GPLv2. The violation, if one exists, would likely be of GPLv2’s §
7. The problem has always been that it’s difficult to actually witness
a v2§7 violation occurring (due in large part to less than perfect
wording of that section). To find a violation v2§7, you have to
discover that there were conditions imposed on [TomTom] … that
contradict the conditions of [GPLv2]. So, we won’t actually know if
this agreement violates GPLv2 unless we read the agreement itself, or if
we observe some behavior by Microsoft or TomTom that shows that the
agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For
TomTom to have agreed to something GPLv2-compliant with Microsoft, the
agreement would have needed to either (a) not grant a patent license at
all (perhaps, for example, Microsoft conceded in the sealed agreement
that the patents aren’t actually enforceable on the GPLv2’d components),
or (b) give a patent license that was royalty-free and permitted all
GPLv2-protected activities by all recipients of patent-practicing
GPLv2’d code from TomTom, or downstream from TomTom.

It’s certainly possible Microsoft either capitulated regarding the
unenforceability (or irrelevancy) of its patents on the GPLv2’d software
in question, or granted some sort of license. We won’t know directly
without seeing the agreement, or by observing a later action by
Microsoft. If, for example, Microsoft later is observed enforcing the
FAT patent against a Linux distributor, one might successfully argue
that the user must have the right to practice those
Microsoft patents in the GPLv2 code, because otherwise, how was TomTom
able to distribute under GPLv2? (Note, BTW, that any
redistributor of Linux could make themselves downstream from TomTom,
since TomTom distributes source on their website.) If no such
permission existed, TomTom would then be caught in a violation —
at least in my (perhaps minority) reading of GPLv2.⁰

Many have argued that GPLv2 § 7 isn’t worded well enough to
verify this line of thinking. I and a few other key GPL thinkers
disagree, mainly because this reading is clearly the intent of GPLv2
when you read the Preamble. But, there are multiple interpretations of
GPLv2’s wording on this issue, and, the wording was written before the
drafters really knew exactly how patents would be used to hurt Free
Software. We’ll thus probably never really have complete certainty that
such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like
it whose existence is not public, because lawsuits aren’t involved)
almost surely plays into this interpretation ambiguity. Microsoft
likely convinced TomTom that the deal is GPLv2-compliant, and that’s why
there are so many statements in the press opining about its likely GPLv2
compliance. I, Jeremy Allison, and others might be in the minority in
our belief of the strength of GPLv2 § 7, but no one can disagree
with the intent of the section, as stated in the Preamble. Microsoft is
manipulating the interpretation disagreements to convince smaller
companies like Novell, TomTom, and probably others into believing that
these complicated patent licensing deals and/or covenants are
GPLv2-compliant. Since most of them are about the kernel named Linux,
and the Linux copyright holders are the only ones with power to enforce,
Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the
situation. Therefore, this is a great moment in our community to
reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal,
considered carefully how to address these sorts of agreements.
Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

A patent license is “discriminatory” if it does not include
within the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is in
the business of distributing software, under which you make payment to the
third party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who would
receive the covered work from you, a discriminatory patent license (a) in
connection with copies of the covered work conveyed by you (or copies made
from those copies), or (b) primarily for and in connection with specific
products or compilations that contain the covered work, unless you entered
into that arrangement, or that patent license was granted, prior to 28
March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those
in the second paragraph, would clearly and unequivocally prohibit TomTom
from entering into any arrangement with Microsoft that doesn’t grant a
license to any Microsoft patent that reads on Linux. Indeed, even what
has been publicly said about this agreement seems to indicate strongly
that this deal would violate GPLv3. While the Novell/Microsoft deal was
grandfathered in (via the date above), this new agreement is not. Yet,
the most frustrating aspect of the press coverage of this deal is that
few have taken the opportunity to advocate for GPLv3 adoption by more
projects. I hope now that we’re a few weeks out from the coverage,
project leaders will begin again to consider adding this additional
patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should
explain a bit why special patent licensing deals like this are bad for
software freedom; it’s not completely obvious. To do so, we can look
specifically at what TomTom and Microsoft said in the press coverage of
their deal: The agreement protects TomTom’s customers under the
patents …, the companies said
(Microsoft,
TomTom Settle Patent Dispute, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort
of “patent protection” to TomTom customers,
and presumably no one else. This means that if someone buys a
GNU/Linux-based TomTom product, they have greater protection from
Microsoft’s patents than if they don’t. It creates two unequal classes of
users: those who pay TomTom and those who don’t. The ones who don’t pay
TomTom will have to worry if they will be the next ones sued or attacked
in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is
precisely what all versions of the GPL seek to prevent. This is why the
Preamble of GPLv2 said: any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a
free program will individually obtain patent licenses, in effect making
the program proprietary.

Further to this point, in
the Rationale
Document for the Third Discussion Draft of GPLv3, a similar
argument is given in more detail:

The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to the
extent that users feel compelled, by the threat of the patent, to get
their copies in this way. So far, the Microsoft/Novell deal does not seem
to have had this result, or at least not very much: users do not seem to
be choosing Novell for this reason. But we cannot take for granted that
such threats will always fail to harm the community. We take the threat
seriously, and we have decided to act to block such threats, and to reduce
their potential to do harm. Such deals also offer patent holders a crack
through which to split the community. Offering commercial users the chance
to buy limited promises of patent safety in effect invites each of them to
make a separate peace with patent aggressors, and abandon the rest of our
community to its fate.

It’s true that one can blissfully use, redistribute, sell and modify
some patent-covered software for years without ever facing a patent
enforcement action. But, particularly in situations where known patents
have been asserted, those without a patent license often live in fear of
copying, modifying and sharing code that exercises the teachings of the
patent. We saw this throughout the 1990s with RSA, and today most
commonly with audio and video codecs. Microsoft and other anti-Free
Software companies have enough patents to attack if we let them. The
first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3
with the improved patent provisions, and (b) condemning GPLv2-only deals
that solve a patent problem for some users but leave the rest out in the
cold, and (c) pointing out that the purported certainty that such deals
are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under
GPLv2 has probably been underestimated, we cannot overestimate the
additional protection that GPLv3 gives us in this regard. Microsoft
clearly knows that the GPLv3 terms will kill their patent aggression
business model, and have therefore focused their attacks on
GPLv2-licensed code. Shouldn’t we start to flank them by making less
GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom,
as a company, is not necessarily an ally of software freedom. They are
like most for-profit companies; they use FLOSS when it is convenient for
them, and give back when the licenses obligate them to do so, or when it
behooves them in some way. As a for-profit company, they made this deal
to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their
products was done legitimately (that
is, once
their GPLv2 non-compliance was corrected by Harald Welte in 2004).
However, I do not think we should look upon TomTom as a particularly
helpful member of the community. Indeed, most of the patents that
Microsoft asserted against TomTom were on their proprietary components,
not their FLOSS ones. Thus, most of this dispute was a proprietary
software company arguing with another proprietary software company over
patents that read on proprietary software. Our community should tell
TomTom that if they want to join and support the FLOSS world, they
should release their software under a FLOSS license — including
software that they aren’t obligated to do so by the licenses. Wouldn’t it be quite interesting if TomTom’s mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom’s patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn’t they allow us to at least practice the teachings of their patents in GPL’d software?

⁰Update:
Andrew Tridgell pointed out that my verb tenses in my hypothetical example
made the text sound more broadly worded than I intended. I’ve thus
corrected the text in the hypothetical example to be clearer. Thanks for
the clarification, Tridge!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/16/tomtom-microsoft.html

There has been a lot of press coverage about the Microsoft/TomTom
settlement. Unfortunately, so far, I have seen no one speak directly
about the dangers that this deal could pose to software freedom, and
what our community should consider in its wake. Karen and I discussed
some of these
details on
our podcast, but I thought it would be useful to have a blog post
about this issue as well.

Most settlement agreements are sealed. This means that we won’t ever
actually know what TomTom agreed to and whether or not it violates
GPLv2. The violation, if one exists, would likely be of GPLv2’s §
7. The problem has always been that it’s difficult to actually witness
a v2§7 violation occurring (due in large part to less than perfect
wording of that section). To find a violation v2§7, you have to
discover that there were conditions imposed on [TomTom] … that
contradict the conditions of [GPLv2]. So, we won’t actually know if
this agreement violates GPLv2 unless we read the agreement itself, or if
we observe some behavior by Microsoft or TomTom that shows that the
agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For
TomTom to have agreed to something GPLv2-compliant with Microsoft, the
agreement would have needed to either (a) not grant a patent license at
all (perhaps, for example, Microsoft conceded in the sealed agreement
that the patents aren’t actually enforceable on the GPLv2’d components),
or (b) give a patent license that was royalty-free and permitted all
GPLv2-protected activities by all recipients of patent-practicing
GPLv2’d code from TomTom, or downstream from TomTom.

It’s certainly possible Microsoft either capitulated regarding the
unenforceability (or irrelevancy) of its patents on the GPLv2’d software
in question, or granted some sort of license. We won’t know directly
without seeing the agreement, or by observing a later action by
Microsoft. If, for example, Microsoft later is observed enforcing the
FAT patent against a Linux distributor, one might successfully argue
that the user must have the right to practice those
Microsoft patents in the GPLv2 code, because otherwise, how was TomTom
able to distribute under GPLv2? (Note, BTW, that any
redistributor of Linux could make themselves downstream from TomTom,
since TomTom distributes source on their website.) If no such
permission existed, TomTom would then be caught in a violation —
at least in my (perhaps minority) reading of GPLv2.⁰

Many have argued that GPLv2 § 7 isn’t worded well enough to
verify this line of thinking. I and a few other key GPL thinkers
disagree, mainly because this reading is clearly the intent of GPLv2
when you read the Preamble. But, there are multiple interpretations of
GPLv2’s wording on this issue, and, the wording was written before the
drafters really knew exactly how patents would be used to hurt Free
Software. We’ll thus probably never really have complete certainty that
such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like
it whose existence is not public, because lawsuits aren’t involved)
almost surely plays into this interpretation ambiguity. Microsoft
likely convinced TomTom that the deal is GPLv2-compliant, and that’s why
there are so many statements in the press opining about its likely GPLv2
compliance. I, Jeremy Allison, and others might be in the minority in
our belief of the strength of GPLv2 § 7, but no one can disagree
with the intent of the section, as stated in the Preamble. Microsoft is
manipulating the interpretation disagreements to convince smaller
companies like Novell, TomTom, and probably others into believing that
these complicated patent licensing deals and/or covenants are
GPLv2-compliant. Since most of them are about the kernel named Linux,
and the Linux copyright holders are the only ones with power to enforce,
Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the
situation. Therefore, this is a great moment in our community to
reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal,
considered carefully how to address these sorts of agreements.
Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

A patent license is “discriminatory” if it does not include
within the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is in
the business of distributing software, under which you make payment to the
third party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who would
receive the covered work from you, a discriminatory patent license (a) in
connection with copies of the covered work conveyed by you (or copies made
from those copies), or (b) primarily for and in connection with specific
products or compilations that contain the covered work, unless you entered
into that arrangement, or that patent license was granted, prior to 28
March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those
in the second paragraph, would clearly and unequivocally prohibit TomTom
from entering into any arrangement with Microsoft that doesn’t grant a
license to any Microsoft patent that reads on Linux. Indeed, even what
has been publicly said about this agreement seems to indicate strongly
that this deal would violate GPLv3. While the Novell/Microsoft deal was
grandfathered in (via the date above), this new agreement is not. Yet,
the most frustrating aspect of the press coverage of this deal is that
few have taken the opportunity to advocate for GPLv3 adoption by more
projects. I hope now that we’re a few weeks out from the coverage,
project leaders will begin again to consider adding this additional
patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should
explain a bit why special patent licensing deals like this are bad for
software freedom; it’s not completely obvious. To do so, we can look
specifically at what TomTom and Microsoft said in the press coverage of
their deal: The agreement protects TomTom’s customers under the
patents …, the companies said
(Microsoft,
TomTom Settle Patent Dispute, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort
of “patent protection” to TomTom customers,
and presumably no one else. This means that if someone buys a
GNU/Linux-based TomTom product, they have greater protection from
Microsoft’s patents than if they don’t. It creates two unequal classes of
users: those who pay TomTom and those who don’t. The ones who don’t pay
TomTom will have to worry if they will be the next ones sued or attacked
in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is
precisely what all versions of the GPL seek to prevent. This is why the
Preamble of GPLv2 said: any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a
free program will individually obtain patent licenses, in effect making
the program proprietary.

Further to this point, in
the Rationale
Document for the Third Discussion Draft of GPLv3, a similar
argument is given in more detail:

The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to the
extent that users feel compelled, by the threat of the patent, to get
their copies in this way. So far, the Microsoft/Novell deal does not seem
to have had this result, or at least not very much: users do not seem to
be choosing Novell for this reason. But we cannot take for granted that
such threats will always fail to harm the community. We take the threat
seriously, and we have decided to act to block such threats, and to reduce
their potential to do harm. Such deals also offer patent holders a crack
through which to split the community. Offering commercial users the chance
to buy limited promises of patent safety in effect invites each of them to
make a separate peace with patent aggressors, and abandon the rest of our
community to its fate.

It’s true that one can blissfully use, redistribute, sell and modify
some patent-covered software for years without ever facing a patent
enforcement action. But, particularly in situations where known patents
have been asserted, those without a patent license often live in fear of
copying, modifying and sharing code that exercises the teachings of the
patent. We saw this throughout the 1990s with RSA, and today most
commonly with audio and video codecs. Microsoft and other anti-Free
Software companies have enough patents to attack if we let them. The
first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3
with the improved patent provisions, and (b) condemning GPLv2-only deals
that solve a patent problem for some users but leave the rest out in the
cold, and (c) pointing out that the purported certainty that such deals
are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under
GPLv2 has probably been underestimated, we cannot overestimate the
additional protection that GPLv3 gives us in this regard. Microsoft
clearly knows that the GPLv3 terms will kill their patent aggression
business model, and have therefore focused their attacks on
GPLv2-licensed code. Shouldn’t we start to flank them by making less
GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom,
as a company, is not necessarily an ally of software freedom. They are
like most for-profit companies; they use FLOSS when it is convenient for
them, and give back when the licenses obligate them to do so, or when it
behooves them in some way. As a for-profit company, they made this deal
to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their
products was done legitimately (that
is, once
their GPLv2 non-compliance was corrected by Harald Welte in 2004).
However, I do not think we should look upon TomTom as a particularly
helpful member of the community. Indeed, most of the patents that
Microsoft asserted against TomTom were on their proprietary components,
not their FLOSS ones. Thus, most of this dispute was a proprietary
software company arguing with another proprietary software company over
patents that read on proprietary software. Our community should tell
TomTom that if they want to join and support the FLOSS world, they
should release their software under a FLOSS license — including
software that they aren’t obligated to do so by the licenses. Wouldn’t it be quite interesting if TomTom’s mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom’s patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn’t they allow us to at least practice the teachings of their patents in GPL’d software?

⁰Update:
Andrew Tridgell pointed out that my verb tenses in my hypothetical example
made the text sound more broadly worded than I intended. I’ve thus
corrected the text in the hypothetical example to be clearer. Thanks for
the clarification, Tridge!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/16/tomtom-microsoft.html

There has been a lot of press coverage about the Microsoft/TomTom
settlement. Unfortunately, so far, I have seen no one speak directly
about the dangers that this deal could pose to software freedom, and
what our community should consider in its wake. Karen and I discussed
some of these
details on
our podcast, but I thought it would be useful to have a blog post
about this issue as well.

Most settlement agreements are sealed. This means that we won’t ever
actually know what TomTom agreed to and whether or not it violates
GPLv2. The violation, if one exists, would likely be of GPLv2’s §
7. The problem has always been that it’s difficult to actually witness
a v2§7 violation occurring (due in large part to less than perfect
wording of that section). To find a violation v2§7, you have to
discover that there were conditions imposed on [TomTom] … that
contradict the conditions of [GPLv2]. So, we won’t actually know if
this agreement violates GPLv2 unless we read the agreement itself, or if
we observe some behavior by Microsoft or TomTom that shows that the
agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For
TomTom to have agreed to something GPLv2-compliant with Microsoft, the
agreement would have needed to either (a) not grant a patent license at
all (perhaps, for example, Microsoft conceded in the sealed agreement
that the patents aren’t actually enforceable on the GPLv2’d components),
or (b) give a patent license that was royalty-free and permitted all
GPLv2-protected activities by all recipients of patent-practicing
GPLv2’d code from TomTom, or downstream from TomTom.

It’s certainly possible Microsoft either capitulated regarding the
unenforceability (or irrelevancy) of its patents on the GPLv2’d software
in question, or granted some sort of license. We won’t know directly
without seeing the agreement, or by observing a later action by
Microsoft. If, for example, Microsoft later is observed enforcing the
FAT patent against a Linux distributor, one might successfully argue
that the user must have the right to practice those
Microsoft patents in the GPLv2 code, because otherwise, how was TomTom
able to distribute under GPLv2? (Note, BTW, that any
redistributor of Linux could make themselves downstream from TomTom,
since TomTom distributes source on their website.) If no such
permission existed, TomTom would then be caught in a violation —
at least in my (perhaps minority) reading of GPLv2.⁰

Many have argued that GPLv2 § 7 isn’t worded well enough to
verify this line of thinking. I and a few other key GPL thinkers
disagree, mainly because this reading is clearly the intent of GPLv2
when you read the Preamble. But, there are multiple interpretations of
GPLv2’s wording on this issue, and, the wording was written before the
drafters really knew exactly how patents would be used to hurt Free
Software. We’ll thus probably never really have complete certainty that
such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like
it whose existence is not public, because lawsuits aren’t involved)
almost surely plays into this interpretation ambiguity. Microsoft
likely convinced TomTom that the deal is GPLv2-compliant, and that’s why
there are so many statements in the press opining about its likely GPLv2
compliance. I, Jeremy Allison, and others might be in the minority in
our belief of the strength of GPLv2 § 7, but no one can disagree
with the intent of the section, as stated in the Preamble. Microsoft is
manipulating the interpretation disagreements to convince smaller
companies like Novell, TomTom, and probably others into believing that
these complicated patent licensing deals and/or covenants are
GPLv2-compliant. Since most of them are about the kernel named Linux,
and the Linux copyright holders are the only ones with power to enforce,
Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the
situation. Therefore, this is a great moment in our community to
reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal,
considered carefully how to address these sorts of agreements.
Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

A patent license is “discriminatory” if it does not include
within the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is in
the business of distributing software, under which you make payment to the
third party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who would
receive the covered work from you, a discriminatory patent license (a) in
connection with copies of the covered work conveyed by you (or copies made
from those copies), or (b) primarily for and in connection with specific
products or compilations that contain the covered work, unless you entered
into that arrangement, or that patent license was granted, prior to 28
March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those
in the second paragraph, would clearly and unequivocally prohibit TomTom
from entering into any arrangement with Microsoft that doesn’t grant a
license to any Microsoft patent that reads on Linux. Indeed, even what
has been publicly said about this agreement seems to indicate strongly
that this deal would violate GPLv3. While the Novell/Microsoft deal was
grandfathered in (via the date above), this new agreement is not. Yet,
the most frustrating aspect of the press coverage of this deal is that
few have taken the opportunity to advocate for GPLv3 adoption by more
projects. I hope now that we’re a few weeks out from the coverage,
project leaders will begin again to consider adding this additional
patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should
explain a bit why special patent licensing deals like this are bad for
software freedom; it’s not completely obvious. To do so, we can look
specifically at what TomTom and Microsoft said in the press coverage of
their deal: The agreement protects TomTom’s customers under the
patents …, the companies said
(Microsoft,
TomTom Settle Patent Dispute, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort
of “patent protection” to TomTom customers,
and presumably no one else. This means that if someone buys a
GNU/Linux-based TomTom product, they have greater protection from
Microsoft’s patents than if they don’t. It creates two unequal classes of
users: those who pay TomTom and those who don’t. The ones who don’t pay
TomTom will have to worry if they will be the next ones sued or attacked
in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is
precisely what all versions of the GPL seek to prevent. This is why the
Preamble of GPLv2 said: any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a
free program will individually obtain patent licenses, in effect making
the program proprietary.

Further to this point, in
the Rationale
Document for the Third Discussion Draft of GPLv3, a similar
argument is given in more detail:

The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to the
extent that users feel compelled, by the threat of the patent, to get
their copies in this way. So far, the Microsoft/Novell deal does not seem
to have had this result, or at least not very much: users do not seem to
be choosing Novell for this reason. But we cannot take for granted that
such threats will always fail to harm the community. We take the threat
seriously, and we have decided to act to block such threats, and to reduce
their potential to do harm. Such deals also offer patent holders a crack
through which to split the community. Offering commercial users the chance
to buy limited promises of patent safety in effect invites each of them to
make a separate peace with patent aggressors, and abandon the rest of our
community to its fate.

It’s true that one can blissfully use, redistribute, sell and modify
some patent-covered software for years without ever facing a patent
enforcement action. But, particularly in situations where known patents
have been asserted, those without a patent license often live in fear of
copying, modifying and sharing code that exercises the teachings of the
patent. We saw this throughout the 1990s with RSA, and today most
commonly with audio and video codecs. Microsoft and other anti-Free
Software companies have enough patents to attack if we let them. The
first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3
with the improved patent provisions, and (b) condemning GPLv2-only deals
that solve a patent problem for some users but leave the rest out in the
cold, and (c) pointing out that the purported certainty that such deals
are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under
GPLv2 has probably been underestimated, we cannot overestimate the
additional protection that GPLv3 gives us in this regard. Microsoft
clearly knows that the GPLv3 terms will kill their patent aggression
business model, and have therefore focused their attacks on
GPLv2-licensed code. Shouldn’t we start to flank them by making less
GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom,
as a company, is not necessarily an ally of software freedom. They are
like most for-profit companies; they use FLOSS when it is convenient for
them, and give back when the licenses obligate them to do so, or when it
behooves them in some way. As a for-profit company, they made this deal
to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their
products was done legitimately (that
is, once
their GPLv2 non-compliance was corrected by Harald Welte in 2004).
However, I do not think we should look upon TomTom as a particularly
helpful member of the community. Indeed, most of the patents that
Microsoft asserted against TomTom were on their proprietary components,
not their FLOSS ones. Thus, most of this dispute was a proprietary
software company arguing with another proprietary software company over
patents that read on proprietary software. Our community should tell
TomTom that if they want to join and support the FLOSS world, they
should release their software under a FLOSS license — including
software that they aren’t obligated to do so by the licenses. Wouldn’t it be quite interesting if TomTom’s mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom’s patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn’t they allow us to at least practice the teachings of their patents in GPL’d software?

⁰Update:
Andrew Tridgell pointed out that my verb tenses in my hypothetical example
made the text sound more broadly worded than I intended. I’ve thus
corrected the text in the hypothetical example to be clearer. Thanks for
the clarification, Tridge!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/16/tomtom-microsoft.html

There has been a lot of press coverage about the Microsoft/TomTom
settlement. Unfortunately, so far, I have seen no one speak directly
about the dangers that this deal could pose to software freedom, and
what our community should consider in its wake. Karen and I discussed
some of these
details on
our podcast, but I thought it would be useful to have a blog post
about this issue as well.

Most settlement agreements are sealed. This means that we won’t ever
actually know what TomTom agreed to and whether or not it violates
GPLv2. The violation, if one exists, would likely be of GPLv2’s §
7. The problem has always been that it’s difficult to actually witness
a v2§7 violation occurring (due in large part to less than perfect
wording of that section). To find a violation v2§7, you have to
discover that there were conditions imposed on [TomTom] … that
contradict the conditions of [GPLv2]. So, we won’t actually know if
this agreement violates GPLv2 unless we read the agreement itself, or if
we observe some behavior by Microsoft or TomTom that shows that the
agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For
TomTom to have agreed to something GPLv2-compliant with Microsoft, the
agreement would have needed to either (a) not grant a patent license at
all (perhaps, for example, Microsoft conceded in the sealed agreement
that the patents aren’t actually enforceable on the GPLv2’d components),
or (b) give a patent license that was royalty-free and permitted all
GPLv2-protected activities by all recipients of patent-practicing
GPLv2’d code from TomTom, or downstream from TomTom.

It’s certainly possible Microsoft either capitulated regarding the
unenforceability (or irrelevancy) of its patents on the GPLv2’d software
in question, or granted some sort of license. We won’t know directly
without seeing the agreement, or by observing a later action by
Microsoft. If, for example, Microsoft later is observed enforcing the
FAT patent against a Linux distributor, one might successfully argue
that the user must have the right to practice those
Microsoft patents in the GPLv2 code, because otherwise, how was TomTom
able to distribute under GPLv2? (Note, BTW, that any
redistributor of Linux could make themselves downstream from TomTom,
since TomTom distributes source on their website.) If no such
permission existed, TomTom would then be caught in a violation —
at least in my (perhaps minority) reading of GPLv2.⁰

Many have argued that GPLv2 § 7 isn’t worded well enough to
verify this line of thinking. I and a few other key GPL thinkers
disagree, mainly because this reading is clearly the intent of GPLv2
when you read the Preamble. But, there are multiple interpretations of
GPLv2’s wording on this issue, and, the wording was written before the
drafters really knew exactly how patents would be used to hurt Free
Software. We’ll thus probably never really have complete certainty that
such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like
it whose existence is not public, because lawsuits aren’t involved)
almost surely plays into this interpretation ambiguity. Microsoft
likely convinced TomTom that the deal is GPLv2-compliant, and that’s why
there are so many statements in the press opining about its likely GPLv2
compliance. I, Jeremy Allison, and others might be in the minority in
our belief of the strength of GPLv2 § 7, but no one can disagree
with the intent of the section, as stated in the Preamble. Microsoft is
manipulating the interpretation disagreements to convince smaller
companies like Novell, TomTom, and probably others into believing that
these complicated patent licensing deals and/or covenants are
GPLv2-compliant. Since most of them are about the kernel named Linux,
and the Linux copyright holders are the only ones with power to enforce,
Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the
situation. Therefore, this is a great moment in our community to
reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal,
considered carefully how to address these sorts of agreements.
Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

A patent license is “discriminatory” if it does not include
within the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is in
the business of distributing software, under which you make payment to the
third party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who would
receive the covered work from you, a discriminatory patent license (a) in
connection with copies of the covered work conveyed by you (or copies made
from those copies), or (b) primarily for and in connection with specific
products or compilations that contain the covered work, unless you entered
into that arrangement, or that patent license was granted, prior to 28
March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those
in the second paragraph, would clearly and unequivocally prohibit TomTom
from entering into any arrangement with Microsoft that doesn’t grant a
license to any Microsoft patent that reads on Linux. Indeed, even what
has been publicly said about this agreement seems to indicate strongly
that this deal would violate GPLv3. While the Novell/Microsoft deal was
grandfathered in (via the date above), this new agreement is not. Yet,
the most frustrating aspect of the press coverage of this deal is that
few have taken the opportunity to advocate for GPLv3 adoption by more
projects. I hope now that we’re a few weeks out from the coverage,
project leaders will begin again to consider adding this additional
patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should
explain a bit why special patent licensing deals like this are bad for
software freedom; it’s not completely obvious. To do so, we can look
specifically at what TomTom and Microsoft said in the press coverage of
their deal: The agreement protects TomTom’s customers under the
patents …, the companies said
(Microsoft,
TomTom Settle Patent Dispute, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort
of “patent protection” to TomTom customers,
and presumably no one else. This means that if someone buys a
GNU/Linux-based TomTom product, they have greater protection from
Microsoft’s patents than if they don’t. It creates two unequal classes of
users: those who pay TomTom and those who don’t. The ones who don’t pay
TomTom will have to worry if they will be the next ones sued or attacked
in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is
precisely what all versions of the GPL seek to prevent. This is why the
Preamble of GPLv2 said: any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a
free program will individually obtain patent licenses, in effect making
the program proprietary.

Further to this point, in
the Rationale
Document for the Third Discussion Draft of GPLv3, a similar
argument is given in more detail:

The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to the
extent that users feel compelled, by the threat of the patent, to get
their copies in this way. So far, the Microsoft/Novell deal does not seem
to have had this result, or at least not very much: users do not seem to
be choosing Novell for this reason. But we cannot take for granted that
such threats will always fail to harm the community. We take the threat
seriously, and we have decided to act to block such threats, and to reduce
their potential to do harm. Such deals also offer patent holders a crack
through which to split the community. Offering commercial users the chance
to buy limited promises of patent safety in effect invites each of them to
make a separate peace with patent aggressors, and abandon the rest of our
community to its fate.

It’s true that one can blissfully use, redistribute, sell and modify
some patent-covered software for years without ever facing a patent
enforcement action. But, particularly in situations where known patents
have been asserted, those without a patent license often live in fear of
copying, modifying and sharing code that exercises the teachings of the
patent. We saw this throughout the 1990s with RSA, and today most
commonly with audio and video codecs. Microsoft and other anti-Free
Software companies have enough patents to attack if we let them. The
first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3
with the improved patent provisions, and (b) condemning GPLv2-only deals
that solve a patent problem for some users but leave the rest out in the
cold, and (c) pointing out that the purported certainty that such deals
are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under
GPLv2 has probably been underestimated, we cannot overestimate the
additional protection that GPLv3 gives us in this regard. Microsoft
clearly knows that the GPLv3 terms will kill their patent aggression
business model, and have therefore focused their attacks on
GPLv2-licensed code. Shouldn’t we start to flank them by making less
GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom,
as a company, is not necessarily an ally of software freedom. They are
like most for-profit companies; they use FLOSS when it is convenient for
them, and give back when the licenses obligate them to do so, or when it
behooves them in some way. As a for-profit company, they made this deal
to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their
products was done legitimately (that
is, once
their GPLv2 non-compliance was corrected by Harald Welte in 2004).
However, I do not think we should look upon TomTom as a particularly
helpful member of the community. Indeed, most of the patents that
Microsoft asserted against TomTom were on their proprietary components,
not their FLOSS ones. Thus, most of this dispute was a proprietary
software company arguing with another proprietary software company over
patents that read on proprietary software. Our community should tell
TomTom that if they want to join and support the FLOSS world, they
should release their software under a FLOSS license — including
software that they aren’t obligated to do so by the licenses. Wouldn’t it be quite interesting if TomTom’s mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom’s patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn’t they allow us to at least practice the teachings of their patents in GPL’d software?

⁰Update:
Andrew Tridgell pointed out that my verb tenses in my hypothetical example
made the text sound more broadly worded than I intended. I’ve thus
corrected the text in the hypothetical example to be clearer. Thanks for
the clarification, Tridge!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/16/tomtom-microsoft.html

There has been a lot of press coverage about the Microsoft/TomTom
settlement. Unfortunately, so far, I have seen no one speak directly
about the dangers that this deal could pose to software freedom, and
what our community should consider in its wake. Karen and I discussed
some of these
details on
our podcast, but I thought it would be useful to have a blog post
about this issue as well.

Most settlement agreements are sealed. This means that we won’t ever
actually know what TomTom agreed to and whether or not it violates
GPLv2. The violation, if one exists, would likely be of GPLv2’s §
7. The problem has always been that it’s difficult to actually witness
a v2§7 violation occurring (due in large part to less than perfect
wording of that section). To find a violation v2§7, you have to
discover that there were conditions imposed on [TomTom] … that
contradict the conditions of [GPLv2]. So, we won’t actually know if
this agreement violates GPLv2 unless we read the agreement itself, or if
we observe some behavior by Microsoft or TomTom that shows that the
agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For
TomTom to have agreed to something GPLv2-compliant with Microsoft, the
agreement would have needed to either (a) not grant a patent license at
all (perhaps, for example, Microsoft conceded in the sealed agreement
that the patents aren’t actually enforceable on the GPLv2’d components),
or (b) give a patent license that was royalty-free and permitted all
GPLv2-protected activities by all recipients of patent-practicing
GPLv2’d code from TomTom, or downstream from TomTom.

It’s certainly possible Microsoft either capitulated regarding the
unenforceability (or irrelevancy) of its patents on the GPLv2’d software
in question, or granted some sort of license. We won’t know directly
without seeing the agreement, or by observing a later action by
Microsoft. If, for example, Microsoft later is observed enforcing the
FAT patent against a Linux distributor, one might successfully argue
that the user must have the right to practice those
Microsoft patents in the GPLv2 code, because otherwise, how was TomTom
able to distribute under GPLv2? (Note, BTW, that any
redistributor of Linux could make themselves downstream from TomTom,
since TomTom distributes source on their website.) If no such
permission existed, TomTom would then be caught in a violation —
at least in my (perhaps minority) reading of GPLv2.⁰

Many have argued that GPLv2 § 7 isn’t worded well enough to
verify this line of thinking. I and a few other key GPL thinkers
disagree, mainly because this reading is clearly the intent of GPLv2
when you read the Preamble. But, there are multiple interpretations of
GPLv2’s wording on this issue, and, the wording was written before the
drafters really knew exactly how patents would be used to hurt Free
Software. We’ll thus probably never really have complete certainty that
such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like
it whose existence is not public, because lawsuits aren’t involved)
almost surely plays into this interpretation ambiguity. Microsoft
likely convinced TomTom that the deal is GPLv2-compliant, and that’s why
there are so many statements in the press opining about its likely GPLv2
compliance. I, Jeremy Allison, and others might be in the minority in
our belief of the strength of GPLv2 § 7, but no one can disagree
with the intent of the section, as stated in the Preamble. Microsoft is
manipulating the interpretation disagreements to convince smaller
companies like Novell, TomTom, and probably others into believing that
these complicated patent licensing deals and/or covenants are
GPLv2-compliant. Since most of them are about the kernel named Linux,
and the Linux copyright holders are the only ones with power to enforce,
Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the
situation. Therefore, this is a great moment in our community to
reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal,
considered carefully how to address these sorts of agreements.
Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

A patent license is “discriminatory” if it does not include
within the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is in
the business of distributing software, under which you make payment to the
third party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who would
receive the covered work from you, a discriminatory patent license (a) in
connection with copies of the covered work conveyed by you (or copies made
from those copies), or (b) primarily for and in connection with specific
products or compilations that contain the covered work, unless you entered
into that arrangement, or that patent license was granted, prior to 28
March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those
in the second paragraph, would clearly and unequivocally prohibit TomTom
from entering into any arrangement with Microsoft that doesn’t grant a
license to any Microsoft patent that reads on Linux. Indeed, even what
has been publicly said about this agreement seems to indicate strongly
that this deal would violate GPLv3. While the Novell/Microsoft deal was
grandfathered in (via the date above), this new agreement is not. Yet,
the most frustrating aspect of the press coverage of this deal is that
few have taken the opportunity to advocate for GPLv3 adoption by more
projects. I hope now that we’re a few weeks out from the coverage,
project leaders will begin again to consider adding this additional
patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should
explain a bit why special patent licensing deals like this are bad for
software freedom; it’s not completely obvious. To do so, we can look
specifically at what TomTom and Microsoft said in the press coverage of
their deal: The agreement protects TomTom’s customers under the
patents …, the companies said
(Microsoft,
TomTom Settle Patent Dispute, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort
of “patent protection” to TomTom customers,
and presumably no one else. This means that if someone buys a
GNU/Linux-based TomTom product, they have greater protection from
Microsoft’s patents than if they don’t. It creates two unequal classes of
users: those who pay TomTom and those who don’t. The ones who don’t pay
TomTom will have to worry if they will be the next ones sued or attacked
in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is
precisely what all versions of the GPL seek to prevent. This is why the
Preamble of GPLv2 said: any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a
free program will individually obtain patent licenses, in effect making
the program proprietary.

Further to this point, in
the Rationale
Document for the Third Discussion Draft of GPLv3, a similar
argument is given in more detail:

The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to the
extent that users feel compelled, by the threat of the patent, to get
their copies in this way. So far, the Microsoft/Novell deal does not seem
to have had this result, or at least not very much: users do not seem to
be choosing Novell for this reason. But we cannot take for granted that
such threats will always fail to harm the community. We take the threat
seriously, and we have decided to act to block such threats, and to reduce
their potential to do harm. Such deals also offer patent holders a crack
through which to split the community. Offering commercial users the chance
to buy limited promises of patent safety in effect invites each of them to
make a separate peace with patent aggressors, and abandon the rest of our
community to its fate.

It’s true that one can blissfully use, redistribute, sell and modify
some patent-covered software for years without ever facing a patent
enforcement action. But, particularly in situations where known patents
have been asserted, those without a patent license often live in fear of
copying, modifying and sharing code that exercises the teachings of the
patent. We saw this throughout the 1990s with RSA, and today most
commonly with audio and video codecs. Microsoft and other anti-Free
Software companies have enough patents to attack if we let them. The
first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3
with the improved patent provisions, and (b) condemning GPLv2-only deals
that solve a patent problem for some users but leave the rest out in the
cold, and (c) pointing out that the purported certainty that such deals
are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under
GPLv2 has probably been underestimated, we cannot overestimate the
additional protection that GPLv3 gives us in this regard. Microsoft
clearly knows that the GPLv3 terms will kill their patent aggression
business model, and have therefore focused their attacks on
GPLv2-licensed code. Shouldn’t we start to flank them by making less
GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom,
as a company, is not necessarily an ally of software freedom. They are
like most for-profit companies; they use FLOSS when it is convenient for
them, and give back when the licenses obligate them to do so, or when it
behooves them in some way. As a for-profit company, they made this deal
to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their
products was done legitimately (that
is, once
their GPLv2 non-compliance was corrected by Harald Welte in 2004).
However, I do not think we should look upon TomTom as a particularly
helpful member of the community. Indeed, most of the patents that
Microsoft asserted against TomTom were on their proprietary components,
not their FLOSS ones. Thus, most of this dispute was a proprietary
software company arguing with another proprietary software company over
patents that read on proprietary software. Our community should tell
TomTom that if they want to join and support the FLOSS world, they
should release their software under a FLOSS license — including
software that they aren’t obligated to do so by the licenses. Wouldn’t it be quite interesting if TomTom’s mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom’s patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn’t they allow us to at least practice the teachings of their patents in GPL’d software?

⁰Update:
Andrew Tridgell pointed out that my verb tenses in my hypothetical example
made the text sound more broadly worded than I intended. I’ve thus
corrected the text in the hypothetical example to be clearer. Thanks for
the clarification, Tridge!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/08/neary-copyright-assignment.html

Dave Neary found me during
breakfast at the Linux Collaboration Summit this morning and mentioned
that he was being flamed for a blog post he made,
Copyright
assignment and other barriers to entry. Or, as some might title it
in a Computer Science academic tradition: Copyright Assignment
Considered Harmful. I took a look at Dave’s post, and I
definitely think it’s worth reading and considering, regardless of
whether you agree with it or flame it. For my part, I think I agree
with most of his points.

One of the distinctions that Dave is making that some might miss is the
difference between non-profit, community-controlled copyright assignment
assignees and for-profit copyright assignees. He
quotes
Luis Villa to make the point that companies, ultimately, aren’t the
best destinations as a final home of FLOSS copyrights. If copyright
assignment is looked only through the lens of a for-profit corporate
entity — with only the duty to its shareholders to determine its
future — then indeed it’s a dangerous situation for many of the
reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate
entity is usually problematic. As Dave points out, corporations aren’t
really community members proper of a Free Software community; rather,
their employees typically are. I have always felt that either
copyrights should be assigned to a transparently-run non-profit
501(c)(3) entity, or they should be held by individual contributors.
Indeed, the Samba project even has a
policy
to accept absolutely no corporate copyrights in their codebase, and
I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because
I’ve spent most of my career in the former, and have enjoyed that time
more than my time at the latter. I trust non-profits more because their
charters and founding documents require a duty to a public-benefiting
mission and to a community. They are failing to act properly under
their charters if they put the needs of a for-profit entity ahead of the
needs of the community and the public. This is exactly the correct
alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don’t like centralized copyright for various reasons.
While I do prefer it myself, I can understand this desire among
individuals to each keep their stake of control in the project. Thus, I
don’t object to projects that want each individual contributor to have
their own copyright. In this situation, the incentives are still
properly aligned, because individuals who helped make the project happen
have the legal control. While these individuals have
no required commitment to the public good like a non-profit,
they are members of a community and are much more
likely to put the community needs above the profit motive that controls
all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk
primarily about for-profit corporate assignment. I agree with him on
that point. however, when he mentions that it’s unnecessary, I don’t
completely agree, but he raises well the points that I would raise as to
why it’s important.

However, in the middle of Dave’s post is the bigger concern that
deserves special mention. The important task is keeping a clear record
of the copyright provenance about where the work came from, and who
might have a copyright claim. Copyright assignment is a short-hand way
to do this in an organized and clear fashion. It’s a simple solution
with some overhead, and sometimes projects over the years have been
annoyed with (and even ridiculed) that overhead. However, the more
complex solutions have overhead, too. If you don’t do assignment, you
must keep careful track of every contributor, what their employer
agreements say, and whether they have the right to submit patches under
their own copyrights to the project. Some projects do this better than
others.

Regardless, all of this is hard work. For years, I’ve seen it as a
personal task of mine to help develop systems and recommendations that
help make either process (assignment or good copyright record-keeping)
less burdensome. I haven’t worked on this task as much as I should
have, but I have not forgotten that it needs attention. I envision
integrated hooks and systems with revision control systems that help
with this. I think we eventually need something that makes it trivial
for hackers to implement and easy to maintain. I understand that the
last thing any Free Software hacker wants to do is sit and contemplate
the legal implications of contributions they’ve received. As such, all
of us who follow this issue hope to make it easier for projects to do
the work. In the meantime, I think discussion about this is good, and
I’m thankful for Dave to raising the issue again.