David Bovill wrote:
On 8 January 2011 00:17, Richard Gaskin wrote:
There are scenarios for meaningful sharing that aren't addressed by
GLP-compatible licenses, so while it would be desirable if there were fewer
licenses in the world, the diversity of needs seems to require equally
diverse terms to describe them.
Richard, could you be more specific - apart from the lack of a
"non-commercial" option you can get with CC, I have not come across any
scenarios that you can't address using GPL-compatible licenses. If you could
give an example it would be real useful to me, as it is a main focus of my
work - thanks :)
Short answer:
For some projects it may be desirable, or even necessary, to prevent
forking.
Long answer:
Writing code requires the most valuable non-renewable resource on the
planet: time.
Time always carries a cost. At a minimum, a developer must eat, keep a
roof over their head, and keep the electricity flowing into their
machine while they write.
Recognizing that even free code requires a material cost to produce,
open source can be seen as a rich man's game: because the software is
given away, the money to pay for it must come from some other source.
Many FOSS advocates argue that compensation for code can come from
support and training services. But that position overlooks the
counterproductive nature of such revenue streams: they disincentivise
quality.
If you give software away for free and seek compensation for your
expenses incurred while making it through support and training, you have
no incentive to enhance the product's usability.
On the contrary, if you were to achieve the ideal of making a software
so good that requires no support or training, ironically you risk
killing the project because you'd no longer be able to afford to work on it.
So the uability-minded developer has four alternatives:
1. An egalitarian model, in which those who derive material benefit from
a project contribute materially to the project equally. This is more or
less how most proprietary commercial products support themselves, with
licensing fees.
2. Draw from retained earnings acquired from other directly-compensated
work. This is the "rich man", the man who has made enough money to
enjoy the leisure of working thousands of hours for free.
3. Find a sponsor who has a strategic reason for compensating you. Here
the "rich man" is the sponsor, like IBM pouring millions into Linux
development because it provides them leverage against Microsoft. This
not at all altruism, but of solid business value (see Spolsky's
"Strategy Letter V: Commoditize Your Compliments").
4. Find either direct compensation through advertising on the project's
home page, or through strategic value for yourself by using the project
to enhance the positioning of your consultancy.
This last option requires that you prevent forking:
Imagine that you spend a thousand hours making a truly useful product,
and decide to share it under the GPL.
You spend another hundred hours building an attractive and usable home
page for it, and use your best marketing experience to evangelizing it
so it can be as useful to as many people as possible.
You're able to justify this all of this expense because you believe that
you can either drive enough traffic to your site to earn the money need
to support the project through advertising, or because the traffic will
provide opportunities to grow your consulting business.
Like IBM with Linux, you've found your own strategic benefit to giving
away code, a way of having the project pay for itself without requiring
license fees.
But suppose, as often happens in life, your need to keep a roof over
your head means that you need to take a break from the project shortly
after launch. So while you've just provided tremendous value to the
community, for at least a couple months you simply aren't wealthy enough
to keep giving it your primary focus, and need to spend some time
earning money through other means before you'll have accrued enough to
be able to afford to resume enhancing the project.
In the meantime, I recognize the value of what you've done and would
like to have the same value at my own site.
So rather than contribute new features to the code base hosted at your
site, I simply fork the project and host it at my own.
To justify this to the community, I might spend as much as 50 hours
adding a new feature or two to your work, just enough to make it
worthwhile for the traffic to come to my site instead of yours.
So you spent 1100 hours building a project from scratch and making a
name for it, and I get most of the benefit of that work for a fraction
of the effort.
Had you chosen a Creative Commons license instead of GPL, you would have
been able to share your work just as broadly to as many people as
before, but you would also have had the option of requiring that any
additions to the code base be contributed to the main project, rather
than allowing forked derivatives.
This way a project can grow from the same scope of contributions, but it
keeps the motivating value where most of the expense was incurred, with
the original developer.
If I wanted to contribute to your project I can submit enhancements, and
you could reward such contributions with acknowledgment and links back
to my site.
If that wasn't sufficient to motivate me, I still have the freedom to
spend my own 1100 hours making my own code base.
I recognize that this scenario doesn't apply to all FOSS projects, and
for those it doesn't there are plenty of license options to choose from.
But unless you've either acquired enough spare cash to be able to work
without pay, or find a corporate or governmental sponsor with both their
own deep pockets and a strategic reason to dip into them to pay you,
there is a need for a license that allows a project to be a single
entity, unforkable.
Some purists may feel otherwise, and all are entitled to their own
opinions and to pursue their own projects as they see fit.
But all code incurs material expense to produce, and that expense must
be covered for a project to be viable.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
