Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

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

[Discuss] licensing: who freakin cares?

On Sun, 10 Apr 2016 18:27:11 -0400, Rich Pieri wrote:
> 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.

Right, but what does that have to do with a distributor performing QA
prior to distributing it?

> 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.

We're not talking about second or third party requirements.  We're
talking about first party requirements.  No, said Red Hat developer
working on his own time can't be required to follow Red Hat's QA
procedures for distributing GPL work, but that's neither here nor there.

>> 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:

Nonsense.  You're never required to accept contributions, and
accepting them or not does not restrict your recipients from
performing any distribution they please.  Nothing in the GPL requires
you to *accept* anyone else's distribution.  You can't require them to
adhere to your QA rules, but that's not the same thing as saying that
*you* are not *allowed* to perform QA.

>> 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.

If that's really what they do -- and I have a very hard time believing
that -- it's just plain foolish.  Whoever's running has
every right to say "we're only going to distribute this particular
snapshot of gcc; if you want to distribute your own, find somewhere
else to distribute it from".  And no, *RMS* can't impose restrictions
on gcc, but RMS isn't even working on it any more so far as I know.

> 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.

Again: the Linux kernel is a big GPL project that does not have
governance issues of this kind.
Robert Krawitz                                     <rlk at>

***  MIT Engineers   A Proud Tradition  ***
Member of the League for Programming Freedom  --
Project lead for Gutenprint   --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

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 /