Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] licensing: who freakin cares?



On 4/10/2016 5:04 PM, Robert Krawitz wrote:
> What particular clause of the GPL forbids a distributor from doing QA
> on what s/he distributes?

Freedom 3 in general. GPLv3 Section 5 and 7 in particular but the entire
license applies. You can impose restrictions upon yourself because you
do not receive software from yourself. You cannot impose restrictions
upon recipients of your software other than those that are provided by
the GPL itself.

Section 0 states that "recipients" may be individuals or organizations.
A programmer performing kernel work for hire for Red Hat probably
qualifies as "Red Hat" as the recipient so Red Hat's SQA requirements
are self-imposed. The same programmer working on the kernel on his or
her own time would not be part of the Red Hat organization so being
required to follow Red Hat's SQA policies would be a GPL violation. The
programmer could choose to follow those policies but nobody can require it.

> Licensing something under the GPL does not require *you*, the package
> maintainer, to accept contributions.

Correct. Nothing in the GPL requires anyone to receive free (as in FSF)
software. Still, rejecting contributions because they do not meet your
standards is no different from requiring contributions to meet your
standards before you will accept them which is just another way of
saying SQA. Either way is a technical violation of the GPL and abuse of
your authority as maintainer. By that yardstick, Linus Torvalds is very
abusive, indeed. For example:

https://lkml.org/lkml/2012/12/23/75

> It does mean that you can't impose quality controls on what someone
> else downstream does, but package maintainers -- and downstream
> distributors -- have every right to impose quality controls on what
> they _themselves_ distribute.

All GCC users and developers are downstream from RMS since he wrote the
original. Unlike Red Hat, the group of volunteers who contribute code to
GCC are not an organization. They are a group of volunteers. None among
them can impose SQA practices on each other, nor can RMS impose such
"restrictions" upon them -- which is RMS's own stance on the matter.

Thus I think my assertion stands: the governance problems with GCC
derive from the license. Perhaps "devolve" is a better word than
"derive" but regardless, the license is the root cause of GCC's
dysfunctional management.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org