Prev: 2to3 issues with execfile on python 3.0 on files with encoding
Next: Extract a bordered, skewed rectangle from an image
From: Steven D'Aprano on 15 May 2010 00:19 On Fri, 14 May 2010 07:10:50 -0700, Ed Keith wrote: > But if my client give someone else a copy of the binary I gave them, > they are now in violation. I do not want to put my client in this > position. If your client is distributing software without reading and obeying the licence terms, then they are either idiots, or unethical, or possibly both. If you want to make life easier on them by reducing the consequences of such foolish and/or unethical behaviour, that of course is your right. There are good reasons for doing so, and equally good reasons for not. It's also their right to ask you to assign copyright to them, or to licence the work using the MIT licence (or similar), or to ask for an exclusive licence. Or even to ask you to sign a "no compete" agreement which prevents you from ever writing code again. It's your choice whether to say Yay or Nay, and if you agree, how much you will charge for it. > When using the GPL or LGPL you can do anything you want as long as you > do not let anyone else use your work, but if you let someone else have a > copy of you work you are putting them in a position where that can > easily/inadvertently violate the law. I do not want to put clients in > legal jeopardy, so I do not use GPL, or LGPLed code. You're not putting them in legal jeopardy, they are. It is their decision whether or not to violate the licence. -- Steven
From: Patrick Maupin on 15 May 2010 00:50 On May 14, 9:59 pm, Steven D'Aprano <st...(a)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
From: Ben Finney on 15 May 2010 00:57 aahz(a)pythoncraft.com (Aahz) writes: > You can't really sell Open Source software in any practical way; > someone will always undercut you once it's out in the wild. You can > only sell support for the software, which is entirely different. Not at all. I've been selling all the software I write for clients for the past ten years, and it's all free software. It's been very practical for me and those I've worked with. You can't sell free software like selling loaves of bread, but that's a much more limited case and a far cry from your claim. Selling free software is quite practical and a good way to fund development of software that otherwise wouldn't be written as free software. -- \ “Why am I an atheist? I ask you: Why is anybody not an atheist? | `\ Everyone starts out being an atheist.” —Andy Rooney, _Boston | _o__) Globe_ 1982-05-30 | Ben Finney
From: Stefan Behnel on 15 May 2010 01:17 aahz(a)pythoncraft.com (Aahz) writes: > Which license you use depends partly on your political philosophy. Did they close down debian-legal, or why is this thread growing so long? Ah, I forgot - Friday ... Stefan
From: Patrick Maupin on 15 May 2010 01:22
On May 14, 11:19 pm, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > On Fri, 14 May 2010 07:10:50 -0700, Ed Keith wrote: > > But if my client give someone else a copy of the binary I gave them, > > they are now in violation. I do not want to put my client in this > > position. > > If your client is distributing software without reading and obeying the > licence terms, then they are either idiots, or unethical, or possibly > both. How about just "ignorant." Maybe even "blissfully ignorant" as in, you just used permissively-licensed software, and since you're not Microsoft and they paid you a fair amount of money for the software and you both agreed on a handshake or a back of the napkin contract that you could both do whatever you wanted with the software (except stripping copyright notices), they go and do exactly that. > If you want to make life easier on them by reducing the consequences of > such foolish and/or unethical behaviour, that of course is your right. > There are good reasons for doing so, and equally good reasons for not. Well, for people who don't feel the imperative of the FSF's prime directive, the only really good reason for "not" is if you found some super-cool GPL-licensed software that will greatly reduce the cost of the contract, *and* you can leverage some of the savings into your own pocket. > It's also their right to ask you to assign copyright to them, or to > licence the work using the MIT licence (or similar), or to ask for an > exclusive licence. Or even to ask you to sign a "no compete" agreement > which prevents you from ever writing code again. It's your choice whether > to say Yay or Nay, and if you agree, how much you will charge for it. Sure, contracts can be made as simple or complex as the parties want. In most cases, reuse of preexisting GPLed software certainly won't simplify the negotiations, though. In Texas, though, that particular "no-compete" wouldn't fly. I'll sign non-compete clauses like that in the blink of an eye; it's the speciously more limited ones that you have to watch out for because sometimes the courts will uphold at least parts of those: http://www.texasnoncompetelaw.com/ > > When using the GPL or LGPL you can do anything you want as long as you > > do not let anyone else use your work, but if you let someone else have a > > copy of you work you are putting them in a position where that can > > easily/inadvertently violate the law. I do not want to put clients in > > legal jeopardy, so I do not use GPL, or LGPLed code. > > You're not putting them in legal jeopardy, they are. It is their decision > whether or not to violate the licence. Uh-huh. If they're in legal jeopardy, you are too (at least in the USA) because the first thing they are going to do is to cross-sue you for failure to explain to them that you were using GPLed software. Doesn't matter if it's not true. Doesn't even matter if you have signed contracts that prove it's not true. It's still going to cost you a pretty penny to get away from the lawsuit. So, really, why go through all that unless it's going to save enough on the contract to justify it? Seriously, a software contract can be less than half a page under some circumstances, and written so that basically you and they can both do whatever you want, and neither is going to sue the other. Regards, Pat |