Re: ADCL

[Al Christians <alc@PublicPropertySoftware.com>]

Yes.  The SLOC percentage doesn't work well at all. I'm in favor
of anything where I can figure ahead of time what it will cost.
Sliding scales or anything else.  Flat rate license like (all) of
the commercial toolkits I use would be best. That way I don't have 
to give TurboAdaComponentsInc the right to come audit me to see how many 
copies I sell.  The SLOC percentage won't work at all.  Some of the 
commercial 3rd party libs I use (paying a flat rate in advance, nothing 
per copy) come without source.  Since these represent the same kind of 
contribution to the result as ADCL-licensed code might make, if we
are paying by percent of the project,  I should get some credit for 
paying this cost, as the other libs do contribute to the project just
like the ADCL code would.  But I don't even know how much source is
in these libs, because I get them without source.  Similarly, if you
are charging based on SLOC, I assume that in Ada you are counting 
semicolons.  But if someone is linking in Lisp or some other functional 
language where you have hemongous nesting and no semicolons, you are
in a lot of trouble.  Same kind of problems if you are dealing with 
code that interprets data soft of like  code. Didn't Von Neumann figure
out that it's hard to tell where the code ends and the data begins?

Al


Marin David Condic wrote:
> 
> 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