on Tue, Oct 23, 2001 at 05:13:38PM -0500, Jim Choate (ravage@einstein.ssz.com) wrote:
On Mon, 22 Oct 2001, Karsten M. Self wrote:
The trend in free software licensing has been strong reluctance to accepting novel licenses.
Right, that's why there are so many of them out there...
Noting, as above, the majority having very low adoption.
Interaction for who, the author or the user?
Interaction between licenses. It's more overhead for the developer to deal with.
Interaction between licenses for who?...
You're using a flawed model. There are three 'roles'; author, distributor, user. Any license must interact with all three roles. The fact is that the license doesn't effect the developer nearly as much as the distributor and the end user. You're only looking at a single layer of interactions.
I'm primarially looking at author/developer interactions. However, all actors are considered. Distributors are concerned with licensing -- this is generally the exposure point for commercial liability, and high-profile distributors will have an aversion to novel or obscure licenses. To this extent, licensing is somewhat like cryptography: well established, well understood licenses which have stood the test of time, are considered lower risk. Again, corporate licenses tend to speak to ghosts in the corporate closet (IBM: Patents, Sun: compatibility and standards control, Corel: Canadian law). Another advantage of selecting a widely use license is that it aquires a strong institutional resistence to sudden change. In the DJB instance cited previously, and the IPFilters licensing "revision" which also effected OpenBSD, licenses which were authored at the sole discretion of a single user were unilateraly modified, or had their interpretation unilaterally changed, to terms not acceptable for broader use. This is less likely where a broader constuency is represented. The authorship / revision issue is one I've put some thought to, there are a few possible solutions.
There is another aspect you're completely ignoring, unless one license prohibits(!) use with another license the interaction (outside of "Can I make money off it?") is nil - both for developers and users.
Free software largely precludes significant revenue streams from software sales. Not always -- Red Hat continues to generate significant revenues from box and corporate sales, though it is moving to a subscription (Red Carpet) and services model. Still, in large part, your benefit is going to come from indirect revenues: services, hardware, publications (e.g.: O'Reilly). Eric Raymond's list from CatB still largely stands. In this case, appeal to developers is *quite* significant, as this distributes your cost structure effectively to unaffiliated partners. This particular lesson is one that a large number of free software businesses (including the one I was affiliated with for 18 months) fail to grasp. There's little specific benefit in direct control of code. IBM, incidentally, is a company that Seems To Get It(tm). Users, similarly, should be concerned with long term viability of code. A project with a single sponsor, and one with troubling financial prospects to boot, doesn't gain much credibility despite their "free software" status. Licensing compatibility emphasizes the inherent "code escrow" powers of free software licensing by providing the possibility that the compelling features of the project might be continued, or at least incorporated into another project, should the initial sponsor fail.
All license start out in the minority. It's a competition in a way.
What are you competing for? What characteristic of a license will "win" the competition?
Utility, which license brings the maximum benefit to all three roles.
Which is served by a mix of factors, significant among them, license compatibility.
This isn't software domination,
Yes, it is.
No. Software itself competes on a different level. It's influenced by the licensing, but isn't fully dictated by this. Poor license choice can severly hamper adoption, development, use, and credibility.
it's more a protocol for collaborative development. Once you've got that nailed down, stop dicking with the damned lawyers, and start writing code.
One shoe doesn't fit all.
There are a good four or five well established "shoes" (GPL, LGPL, BSD/MIT, Mozilla, IBM PSL) which serve a broad range of needs, with a pretty good track record for interoperability. But that's just one idiot to another. Peace. -- Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? Home of the brave http://gestalt-system.sourceforge.net/ Land of the free Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html