Picking a license
in [Python]
|
Prev: 2to3 issues with execfile on python 3.0 on files with encoding
Next: Extract a bordered, skewed rectangle from an image
From: Patrick Maupin on 14 May 2010 22:31 On May 14, 8:57 pm, Lawrence D'Oliveiro <l...(a)geek- central.gen.new_zealand> wrote: > In message <84a26d03-03b3-47d9- > > a1f9-107470b87...(a)k2g2000yqe.googlegroups.com>, Patrick Maupin wrote: > > I also firmly believe, as I have stated before, that the GPL is a much > > more commercial license. If you want to make money off something, > > then, no doubt, GPL keeps your competitors from being able to take > > what you wrote and redistribute it as closed source. But, frankly I > > view that as more of a business issue than a moral issue. > > Nevertheless, its probably a big factor in why the GPL has become the > single most popular open-source licence. Possibly. I think a bigger factor is that the GPL is *designed* to win license competitions. If you view the license as part of the DNA of a piece of software, then whenever two packages "breed" (are combined) the resultant package will always have the GPL if either of the source packages did. In attempting to draw a biological parallel, many have equated the GPL to a virus, but this analogy fails miserably. The "selfish gene" analogy has much to recommend it, however: http://en.wikipedia.org/wiki/The_Selfish_Gene#.22Selfish.22_genes It's an interesting exercise to extend the analogy to show how the GPL gene mutated in a way to allow it to mate with even *more* licenses (and always come out on top). So now there are two incompatible selfish gene FOSS licenses in the ecosystem. The license genes always propagate whenever the host software mates, but in order to have that genetic advantage, they avoid allowing their host software to mate whenever they couldn't be the dominant license gene of the resultant package. One side effect of this is that the two major GPL variants are unable to mate with each other. Regards, Pat
From: Steven D'Aprano on 14 May 2010 22:32 On Fri, 14 May 2010 08:04:53 -0700, Patrick Maupin wrote: > On May 14, 1:08 am, Steven D'Aprano <st...(a)REMOVE-THIS- > cybersource.com.au> wrote: >> On Thu, 13 May 2010 19:10:09 -0700, Patrick Maupin wrote: >> > The broken window fallacy is about labor that could have been spent >> > elsewhere if someone else had done something differently. The only >> > time that comes into play in my programming life is when I have to >> > recode something that is nominally available under the GPL, so I'm >> > not sure this is really making the point you think it is. >> >> You've never had to recode something because it was nominally available >> under a proprietary licence that you (or your client) was unwilling to >> use? Lucky you! > > Don't be silly. That's why I started writing open source software in > the first place. But if I start writing stuff to put in the commons > with strings removed, why would I bother with a license that just adds > some strings back? To maximise the likelihood of it staying in the commons, of course. >> The GPL ensures that once software has entered the commons (and >> therefore available for all), it can never be removed from the commons. > > No it doesn't. It just insures that if people actually *distribute* the > software to others, they have to distribute the source. In any case, > for software to remain in the commons, it has to be available where > people can get to it. Somebody has to care enough to maintain a > repository, or it has to be good enough for people to distribute. The reality is that most software never gets very far. There are millions of packages and libraries and applications which have few than a dozen users, thousands with a few hundred, and only one Microsoft Windows. Since web sites shut down and people lose interest, move on or die, software can disappear. This is a fact of life, and if you're looking for any guarantees, neither the GPL nor MIT-style licence will give you one. But consider the case of Ed Keith, who posted some Boost-licenced software to the commons. (See his message in this thread, about 30 minutes before yours.) The website he posted it to has shut down and he has lost his original code. Obviously no licence can guarantee that people will want to use your software. Unpopular software will remain unpopular no matter what licence you use. But it is precisely the viral nature of the GPL that means that, *if* your software is useful enough for people to want to distribute it, it will remain in the commons even if you, the original author, are hit by a bus, your web server crashes, and you lose the original sources. Under a MIT-style licence, it is possible for you to put a work into the commons, somebody else to copy it and distribute it as a proprietary work, then the original to disappear. For all we know, Ed's software has made it into a thousand different proprietary applications. Nevertheless, it has been lost from the commons, at least until such time as he recreates it. Under the GPL, of course work can be lost from the commons if nobody distributes it and the original is lost. But the viral nature is designed so that *if* the software propagates legally, it remains in the commons and not out of it. This is different from MIT-style licences, which are indifferent to whether the software propagates in the commons or not, and proprietary licences, which typically prohibit it. [...] >> In practice, I believe most MIT-licenced code never even makes it into >> the commons in the first place. > > Interesting assertion. I think it is a safe one. So far in the discussion, you and Ed (and possibly others, I may have forgotten) have repeatedly declared that you use the MIT licence for work you write for clients. This implies two obvious business models: (1) You write open source software, put it on the Internet, and wait for the donations to come flooding in. (2) Clients pay you to write software for them, which you then use a non- GPL open source licence so that they don't need to release the source code if/when they distribute it further. Given that you're able to pay for an Internet connection, chances are that your model is closer to #2. This implies that most of the software you write is bespoke software for clients, which means they're probably not distributing it as open source, simply because most software is still proprietary. >> I'm willing to predict that the majority of code you've written for >> paying customers (as opposed to specifically for open source projects) >> has disappeared into their code base, never to be seen by anyone >> outside of the company. Am I right? > > That's true, but what on earth does that have to do with the MIT > license? The motive behind the GPL is to maximise the amount of code in the commons. The motive behind the MIT is to maximise the convenience, regardless of whether people keep your code in the commons or not. Unless people understand that the *motives* behind the models are different, all this talk of "freedoms" is just talking at cross-purposes. To those who want to maximise code in the commons, allowing people to take code out of the commons isn't a desirable freedom at all; and to those who want to maximise convenience, obliging people to distribute source code isn't desirable either. It's strictly irrelevant to this discussion, but I'm curious why you choose to licence your work to your clients rather than just working for hire and assigning copyright to them. -- Steven
From: Patrick Maupin on 14 May 2010 22:36 On May 14, 9:21 pm, Lawrence D'Oliveiro <l...(a)geek- central.gen.new_zealand> wrote: > In message <mailman.180.1273860694.32709.python-l...(a)python.org>, Ed Keith > wrote: > > > I just refuse to use [the GPL] in any code for a client, because I > > do not want to require someone who does not know source code from Morse > > code code to figure out what they need to do to avoid violating the > > license. > > Why dont you just put the source code on the same disc you send them, and > tell them to pass copies of the entire disc to anyone they want? What you would really have to tell them is "don't pass along the program *unless* you copy the whole disk." That's no longer a courtesy -- that's a mandate. By not using the GPL, Ed avoids having to mandate to his customer how to treat the software he has delivered to them. Regards, Pat
From: Steven D'Aprano on 14 May 2010 22:37 On Fri, 14 May 2010 06:42:31 -0700, Ed Keith wrote: > I am not a lawyer, but as I understand the LGPL, If I give someone > something that used any LGPLed code I must give them the ability to > relink it with any future releases of the LGPLed code. I think that > means that I need to give them a linker and teach them how to use it, > and I do not want to go there. Surely you're joking? Does this mean that if they lose their hands in an accident, you have to come sit at their computer and do their typing? The LGPL and GPL don't grant people "the ability" to do anything, since that's not within our power to grant. Some people don't want to, or can't, program, or don't have time. It's not like the LGPL is the bite of a radioactive spider that can grant superpowers. It is a licence which grants *permissions*. In that regard, that's absolutely no different to the MIT licence, or proprietary software licences, which also deal in permissions (and restrictions). If I go to my local computer retailer and buy a copy of Windows, Microsoft doesn't grant me the ability to run the software. If I say "I don't actually have a computer, and the electricity has been shut off, so you have to pay to have the power turned back on and give me a computer", you won't get anywhere. The licence permits you to run one copy of Windows on one machine. Everything else is up to you. -- Steven
From: Patrick Maupin on 14 May 2010 22:55
On May 14, 9:32 pm, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > > Don't be silly. That's why I started writing open source software in > > the first place. But if I start writing stuff to put in the commons > > with strings removed, why would I bother with a license that just adds > > some strings back? > > To maximise the likelihood of it staying in the commons, of course. Well, it's your opinion that it would do that, and you have some reasonably good reasons for that opinion, but I don't personally buy into all of them. [...] > Obviously no licence can guarantee that people will want to use your > software. Unpopular software will remain unpopular no matter what licence > you use. But it is precisely the viral nature of the GPL that means that, > *if* your software is useful enough for people to want to distribute it, > it will remain in the commons even if you, the original author, are hit > by a bus, your web server crashes, and you lose the original sources. Sure, there's an additional guarantee. But I don't believe there is a real distinction. I believe, for example, that all the major Linux distributions don't try to save bandwidth or disk space by discriminating against non-GPL packages. For example, the Ubuntu policy clearly states that to be in "main" rather than "restricted" a package "must include source code." > Under the GPL, of course work can be lost from the commons if nobody > distributes it and the original is lost. But the viral nature is designed > so that *if* the software propagates legally, it remains in the commons > and not out of it. This is different from MIT-style licences, which are > indifferent to whether the software propagates in the commons or not, and > proprietary licences, which typically prohibit it. While that is a theoretical difference, I don't believe it is a practical one. I don't download all the source for my Linux distro, but they make all the source available. > >> In practice, I believe most MIT-licenced code never even makes it into > >> the commons in the first place. > > > Interesting assertion. > > I think it is a safe one. So far in the discussion, you and Ed (and > possibly others, I may have forgotten) have repeatedly declared that you > use the MIT licence for work you write for clients. I think there is a serious misunderstanding there. For me, there are usually 3 types of licenses involved: 1) proprietary license or work-for-hire agreement for the customer's secret sauce 2) Stuff that the author has put under a permissive license before, or gets the customer to agree is not part of the secret sauce, and the customer agrees to allow the author to put under a permissive license after he writes it 3) Stuff that somebody else wrote under a permissive license For most of my career, I've been an employee with a work-for-hire clause, so pretty much all my writing falls under (1) unless I can make a compelling argument for (2), which is finally starting to happen a bit more. > This implies two > obvious business models: > > (1) You write open source software, put it on the Internet, and wait for > the donations to come flooding in. > > (2) Clients pay you to write software for them, which you then use a non- > GPL open source licence so that they don't need to release the source > code if/when they distribute it further. The bulk of the code is probably (3) Customer dictates the license. [Snipped a bunch of stuff predicated on a misunderstanding of the way things work for me] > It's strictly irrelevant to this discussion, but I'm curious why you > choose to licence your work to your clients rather than just working for > hire and assigning copyright to them. In the past, work-for-hire was practically the rule (during the times I've been an employee). I've been trying to release open stuff from the workplace from over a decade with little traction, but it's finally happening a bit. There are multiple good reasons to open- source, including the hope for coopetition, and the building of a resume. Given that other people who might cooperate with me on an open source project are often similarly situated (working for proprietary employers who wouldn't necessarily want to worry about the GPL), using a permissive license makes great sense. Regards, Pat |