comp.lang.ada
 help / color / mirror / Atom feed
From: "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
Subject: Re: ADCL
Date: Wed, 18 Jul 2001 12:12:12 -0400
Date: 2001-07-18T16:12:16+00:00	[thread overview]
Message-ID: <9j4ch0$6hu$1@nh.pace.co.uk> (raw)
In-Reply-To: 3B55ACAB.3EB3CF69@PublicPropertySoftware.com

O.K. This is a kind of progress. We are at least now talking about how to
structure royalties and not about whether or not they should exist at all.

IMHO, I think that any initial attempt to put code out under a
royalty-bearing open source license ought to be as simple as possible. The
ADCL (as Dr. Leif's paper described it) is a bit tricky in this area. It
seeks to set a price based on usage of the components - which while
reasonably equitable, has the disadvantage that it is tough to calculate and
could be subject to abuse, as you point out. Perhaps a flat rate is better -
with obvious discounts for volume. ($1000 for quantity 1, $2000 for 2..50,
$3000 for 51..500, etc?) Maybe the original developer could set a quantity 1
price on his work & have the ADCL stipulate a standard sliding scale for
multiple copies. Maybe for some things, its better to go on percentage of
gross sales based on percentage of included source. Maybe the license should
have several options?

While I understand the equity of counting volumetric usage, my concern is
that a) no tool currently exists to do this and b) the complexity of it may
drive users away from the deal. (Hard to compute in advance what your costs
are going to be.) I wouldn't worry too much about code padding to create
dilution. In theory, people could do this but in practice I think it would
be sufficiently undesirable for the users to muck up their code this way
that the cost advantage probably wouldn't be worth it. Remember, the big
problem here is that if the license starts costing the user too much, he
goes and builds his own. Hence the argument over "is it 40% or 50% of the
end product?" is going to fall into the weeds if the price/unit becomes too
onerous. Besides, the small-time users who want to cheat you just don't pay
and wait for you to come find them. Its the big ticket items with high
visibility that are going to be an issue for the license and the cost of
cheating in those instances just doesn't make it worth while. (Do you
*really* want to pay lawyers to argue about it for years in court? And
possibly lose? Everything? Or is it cheaper just to pay the guy the royalty
he asked for and get on with it?)

The interesting thing to note is that if there *was* a reasonably simple and
accessible license that had *some* measure of success, it would get the ball
rolling and it is always possible to create specialized versions of it with
different pricing schemes and rates. Sort of like going to Office Max and
picking up standardized contract forms wherein you just fill in the numbers.
The ADCL is what you get as a plain vanilla deal that might suit most uses,
but for those areas where it doesn't work well, the user can always contact
the developer and suggest some other license terms.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <alc@PublicPropertySoftware.com> wrote in message
news:3B55ACAB.3EB3CF69@PublicPropertySoftware.com...
>
> As royalties that depend on how smart the linker is are beyond my ken.
>
> The simplest would be for the author to puplich a flat $ amount per copy
> for commercial use instead of the percent based on SLOC.  Do you really
> want me to just pad my SLOC count to reduce your royalty?  This public
> license with fixed royalty per copy works for music.  With a license
> offering based on flat fee per copy sold, the author can at least take a
> guess at how much advantage his package offers in comparison to whatever
> the competition (commercial, free, write it myself) is, and a whole
> lot of complicated math and what-if questions are cleanly avoided.
>
> The idea (that Ada promoters should promote, I think) is that software
> parts should to embody the same positive qualities that work for
> hardware parts (in reliability, in buy-vs-build comparisons, and in
> ease of interconnection), and pricing  accordingly would strengthen that
> perception.
>
>
> Al





  reply	other threads:[~2001-07-18 16:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.995392315.19704.comp.lang.ada@ada.eu.org>
2001-07-17 18:13 ` The Ada Developers Cooperative License (was Re: Marin David Condic
2001-07-18  5:19   ` Robert C. Leif, Ph.D.
2001-07-18  7:50   ` Robert Dewar
2001-07-18 10:46     ` Larry Kilgallen
2001-07-19 21:49       ` Robert Dewar
     [not found] ` <3B54ACA5.9E286B04@PublicPropertySoftware.com>
2001-07-17 21:41   ` ADCL Marin David Condic
2001-07-18  5:40     ` ADCL Robert C. Leif, Ph.D.
2001-07-18 14:57       ` ADCL Marin David Condic
2001-07-18 15:35       ` ADCL Al Christians
2001-07-18 16:12         ` Marin David Condic [this message]
2001-07-18 17:46           ` ADCL Al Christians
2001-07-19  4:04             ` ADCL Robert C. Leif, Ph.D.
2001-07-19  3:04         ` ADCL Robert C. Leif, Ph.D.
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox