BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] licensing: who freakin cares?
- Subject: [Discuss] licensing: who freakin cares?
- From: rlk at alum.mit.edu (Robert Krawitz)
- Date: Sun, 10 Apr 2016 18:55:11 -0400
- In-reply-to: <570AD33F.3040005@gmail.com> (richard.pieri@gmail.com)
- References: <1E33A4DC-8FF0-4688-87B6-9C61D8AC45CA@icloud.com> <570a8b4d.aa71b60a.caae0.ffff9a3aSMTPIN_ADDED_BROKEN@mx.google.com> <570A9681.9050406@gmail.com> <201604101855.u3AItsmc009245@dsl092-065-009.bos1.dsl.speakeasy.net> <570AB301.7040303@gmail.com> <201604102104.u3AL4FJq009905@dsl092-065-009.bos1.dsl.speakeasy.net> <570AD33F.3040005@gmail.com>
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. > 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. If that's really what they do -- and I have a very hard time believing that -- it's just plain foolish. Whoever's running gcc.gnu.org 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 alum.mit.edu> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
- Follow-Ups:
- [Discuss] licensing: who freakin cares?
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] licensing: who freakin cares?
- References:
- [Discuss] licensing: who freakin cares?
- From: eric.chadbourne at icloud.com (Eric Chadbourne)
- [Discuss] licensing: who freakin cares?
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] licensing: who freakin cares?
- From: rlk at alum.mit.edu (Robert Krawitz)
- [Discuss] licensing: who freakin cares?
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] licensing: who freakin cares?
- From: rlk at alum.mit.edu (Robert Krawitz)
- [Discuss] licensing: who freakin cares?
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] licensing: who freakin cares?
- Prev by Date: [Discuss] Simplest HTML hosting for a 9-year-old engineer?
- Next by Date: [Discuss] licensing: who freakin cares?
- Previous by thread: [Discuss] licensing: who freakin cares?
- Next by thread: [Discuss] licensing: who freakin cares?
- Index(es):