From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,828c115241d90eca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-18 10:42:17 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: Al Christians Newsgroups: comp.lang.ada Subject: Re: ADCL Date: Wed, 18 Jul 2001 10:46:02 -0700 Organization: Public Property Software Message-ID: <3B55CB5A.A768C06@PublicPropertySoftware.com> X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <3B55ACAB.3EB3CF69@PublicPropertySoftware.com> <9j4ch0$6hu$1@nh.pace.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:10178 Date: 2001-07-18T10:46:02-07:00 List-Id: 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" 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