On May 14, 9:59 pm, Steven D'Aprano <st...@remove-this- cybersource.com.au> wrote: > I think this talk about freedoms is dangerously incomplete, and is > confusing the issue rather than shedding more light. Both licences grant > the same positive freedoms (freedom to do something). MIT-style licences > grant permission to: > > * make copies of the work; > * make derivative works based on the work; and > * distribute those derivative works to others. > > The GPL grants precisely the same three rights. There is no difference in > the rights granted. > > The MIT licence imposes an obligation on the licencee: > > * you must include a copy of the licence and copyright notice with the > work and/or any derivative works. > > The GPL adds a further obligation: > > * any derivative works must also be licenced under the GPL. > > If we want to talk about "freedoms", rather than rights and obligations, > we need to distinguish between positive freedoms (freedom to do > something) and negative freedoms (freedoms from something) and not just > blithely mix them up.
That is well-put, and of course the whole purpose of the extra obligation or "negative freedom" is to ensure the rights or "positive freedoms" of downstream recipients of the software. In theoretical terms, everybody who redistributes software under the GPL has the same obligations imposed, but as I have shown in other posts, this obligation is unevenly enforced, and probably by design. In practical terms, the additional obligations of the GPL license are imposed on those who distribute huge quantities of software (Ubuntu, Red Hat) and those who distribute derivative works (by combining other software with the GPLed software). It is questionable whether distributors such as Ubuntu and Red Hat truly see this as an obligation; certainly they also distribute source for permissively-licensed programs, and certainly other parties happily provide source for fully BSD-licensed distributions for free. Nonetheless, some of the smaller derivative distributors undoubtedly wind up paying for more bandwidth than they would like. So, the bulk of the additional obligations fall squarely on people who distribute derivative works. This is by design. It is what keeps the Microsofts of this world from appropriating GPLed software. As I have said many times, for people who worry about this stuff, the GPL is absolutely the right license, because any license that gets them writing free software rather than worrying about freeloaders is a great license. But for someone (let's call him "Fred") who distributes derivative works to a customer, the additional obligation you mention for the GPL actually has 4 separate components: 1) Full source for the original program must be provided 2) Fred's own additional source code must also be provided 3) Fred can't link to any proprietary software at all. 4) Fred must be sure that his customer is OK with the resultant work product being under the GPL. Now, if Fred was going to provide source anyway, the only possible sticking points are really #3 and #4. But those can be very sticky. Let's start with #3. If the proprietary software that is being linked to is, for example, Oracle, Fred can't legally use GPLed software. Well, actually he might be able to, if he writes the software as a work-for-hire (as a contractor for the customer), because then there might not be a true distribution of the final package. So that might actually reduce the amount of free software in the world -- if Fred writes it as work for hire, he can't distribute it to anybody else, and the customer is not about to make a distribution of any of the software, so this is a case where, if Fred can find and leverage permissively licensed software instead of GPLed software, the amount of free software available in the world can actually go up. Now for #4, where Fred just has to communicate with and educate the customer. Even if the customer is just going to use the software in- house with no plans to ever distribute it, the act of merely *asking* a customer if it is OK to use GPLed software in the solution can, in some cases, mean the difference between being able to sign a contract and get started right away, or needing a review by the lawyers that won't conclude for a month and then being told "no" or, even worse, that "business conditions have changed." Obviously, if there were a GPLed solution already available that was the best tool for the job, it might be a good tactic for Fred (if he weren't too worried about the interminable lawyer review) to explain that it will cost $X for a GPL solution, and $X+Y for a non-GPL solution. Or even a good tactic to precede that with a simple question of if the customer ever uses GPL software, and if they already do, do they have a policy. (But that has to be asked in such a way as to not provide an original research question for the lawyer.) But if, starting out, there is no compelling GPLed solution, then there is no good reason to even ask things like that of the customer -- better to just start coding. And if the climate is right to ask if the customer minds if Fred reuses and shares the code, there is a good chance that Fred will use a permissive license on any generic code, if he wants to enable others like himself. So, there are good reasons for both kinds of licenses, which I think everybody on the pro-permissive side has been saying all along. Of course, "force" is a more inflammatory word that "obligation" in some contexts, and that has been used in what I would admit on my part is a knee-jerk reaction to my belief that "free" and "freedom" are more inflammatory words than "rights" in the same contexts. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
