[antonovka]

Only if you own the copyright for the entire body of work. If you receive external contributions, you must request copyright assignment from contributors to allow you (and only you) to use the work for any purpose under any license.

Pro-GPL arguments are full of these silly caveats.

"You can still sell the software" -- so can anyone else, or they can just give it away for free. Now what?

"You can use it under any license you want" -- only if you acquire full copyright for every single contribution.

"You can sell services!" -- end users don't buy "services" for consumer software.

"Non-GPL software is immoral" -- guess who buys the "services" that cover your development costs? Companies that ... sell proprietary software.

.. and just to demonstrate the total rational disconnect of the primary GPL advocate, Mr. Stallman:

http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2963

http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2970

[pyre]

> "You can use it under any license you want" -- only if you acquire full copyright for every single contribution.

This is easy to do. You are the end-point for accepting contributions. All you have to do is require assignment of rights to you in order to accept patches. This is obviously more difficult if you didn't do this to begin with and now have to track down all the past contributors, though.

> "You can sell services!" -- end users don't buy "services" for consumer software.

Depends on what you mean by 'end user.' If the end users for my piece of software are law firms, then yes, they would purchase support contract/other services. Not every piece of software out there is developed for home desktop users.

> "Non-GPL software is immoral" -- guess who buys the "services" that cover your development costs? Companies that ... sell proprietary software.

So the only entities that would purchase support contracts (or custom modifications) for software are proprietary software development houses?

[antonovka]

This is easy to do.

Did you ever try contributing to MySQL? Chances are very good your patch languished for years.

As a contributor, it's a bum deal. I don't like giving away the rights to my work just to support their business model or moral imperative.

Depends on what you mean by 'end user.' If the end users for my piece of software are law firms, then yes, they would purchase support contract/other services.

I literally mean "end user". The consumer who would like a piece of software to solve a particular problem on their desktop. Someone a little like me, who uses the software I'd like to write.

Of course, I don't actually want to provide services -- I want to write software.

So the only entities that would purchase support contracts (or custom modifications) for software are proprietary software development houses?

No, they'll just make up a large portion of your sales (from experience) if you're selling technically-oriented services.

[pyre]

> Did you ever try contributing to MySQL? Chances are very good your patch languished for years.

That has nothing to do with the ease that the software owner can create a system to not have to 'track down all contributors' when making a licensing change decision. Your original post implies that this is a barrier to entry.

> I literally mean "end user". The consumer who would like a piece of software to solve a particular problem on their desktop. Someone a little like me, who uses the software I'd like to write.

So you're suggesting that I can't sell support/services for my 'law firm software' because the paralegal/lawyers that are actually using it on their company desktops will not be paying out of pocket for services? Huh?

> Of course, I don't actually want to provide services -- I want to write software.

No one is forcing you to. I'm not being 'Pro-GPL' here I'm just poking holes in your argument.

> No, they'll just make up a large portion of your sales (from experience) if you're selling technically-oriented services.

(emphasis mine) In your original post you seem to be applying that to all software that someone might choose to make GPL.

[antonovka]

Your original post implies that this is a barrier to entry.

It is a barrier to entry. I provided one example, there are many others. Try participating in the OpenJDK development process. At every turn, you'll find that administering copyright assignment is, bluntly, a gigantic pain in the ass.

As you already noted, it's nearly impossible to put the cat back in the bag, if you fail to do this to begin with.

So you're suggesting that I can't sell support/services for my 'law firm software' because the paralegal/lawyers that are actually using it on their company desktops will not be paying out of pocket for services? Huh?

No. I'm saying that consumers won't buy services for consumer software. If you're selling enterprise support services, you're not selling consumer software to consumers.

No one is forcing you to. I'm not being 'Pro-GPL' here I'm just poking holes in your argument.

A standard argument for the GPL is that you can (should?) sell services, not software.

In your original post you seem to be applying that to all software that someone might choose to make GPL.

If you write software within a narrow band (enterprise, requires support, sold to non-technical organizations) you might be able to make the GPL work for you. Like I said originally: "lots of silly caveats".

[pyre]

> It is a barrier to entry. I provided one example, there are many others. Try participating in the OpenJDK development process. At every turn, you'll find that administering copyright assignment is, bluntly, a gigantic pain in the ass.

IIRC, Samba requires you to assign over rights to contribute. Maybe take a look at their process.

While I will admit that I have no experience with large projects like OpenJDK, I'll venture a guess that the larger a project gets (and/or the more submissions it gets) that harder it is to manage.

GPL is not always realistic with out side effects, but that doesn't mean it's never realistic either (or that it can't be done if you accept the side effects).