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,be23df8e7e275d73 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-09 15:01:43 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "David Starner" Newsgroups: comp.lang.ada Subject: Re: Proving Correctness (was Java Portability) Date: Thu, 9 Aug 2001 21:56:27 +0100 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <9jrt62$38t$1@nh.pace.co.uk> <3B619A6D.5DD6E782@home.com> <3B6636BA.96FD8348@home.com> <9kb3ub$hdo$1@a1-hrz.uni-duisburg.de> <9kchn1$lng$1@a1-hrz.uni-duisburg.de> <9kea9a$lsc$1@nh.pace.co.uk> <9keduf$qvc$1@a1-hrz.uni-duisburg.de> <9kelv1$riq$1@a1-hrz.uni-duisburg.de> <9kosp0$dje$1@nh.pace.co.uk> <9kpq82$otf$1@nh.pace.co.uk> <9krils$fcb$1@nh.pace.co.uk> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:11711 Date: 2001-08-09T21:56:27+01:00 List-Id: [As noted, this was written by Martin Cordic and sent to me for the reasons below.] I couldn't get my newsreader to post a reply to the particular message on the newsgroup. Here's my reply - if you feel like posting it to C.L.A. go ahead. MDC "David Starner" wrote in message news:tn48ce7fdodvbb@corp.supernews.com... > > But there's a difference. The GPL very clearly stops you from distributing > copies without providing source in some way. The "what if"s - sure, you > might be able to evade the GPL if crosswire the COM ports and inject C# > particles, but there are very few parties who have tried, and if someone > gets away with it, you don't lose much. Money, on the other hand, has this > tendency to end up in the wrong pocket and get arguments over whose pocket > it belongs in. If it's just you, than great, but most programs are a lot of > work for a single programmer. If you're willing to form a buisness with your > fellow contributers, you've got the money issues cleared up some, but then > why the ADCL? If you've got 5 major contributers for places around the > world, with 12 minor contributers and a couple dozen bug fixers (like a > mid-sized Open Source project), you've got a problem you really need an > accountant to handle (but accountants get expensive.) > Again, I'm not a lawyer nor do I play one on newsgroups. However, my reading of Dr. Leif's articles & the license seem to indicate to me that if you used ADCL source and *gave* the code to one of your customers, you'd have to *give* them the ADCL source as well. You just wouldn't be forced to give them anything that *you* own - unless you felt like it. You would also be required to give them the ADCL source if you *sold* the product - but wouldn't be required to give them your own part unless you wanted to. In that sense, I think the ADCL is less restrictive than the GPL. Here's another dirty little secret about software licenses: People ignore them *all the time* and use/sell software for which they don't have permission. They steal GPL'ed code, include it in their products, ship it off to their customers without including source, etc. etc. etc. The license doesn't create a garrison of stormtroopers to whup-up on the guys that do this. More or less, its an "honor system". So if both of us put code out there - me under ADCL, you under GPL - we can both bet our rent checks that *someone* is going to use it in violation of the license. In both cases you only want to look for the large, high profile cases. It isn't worth going after the small timers because it costs too much or becomes too complicated to try to stop them. The trick here is to create a scenario where some big concern with some large scale usage is going to look at it and say: "Yeah, we could cheat, but it isn't worth the liability. If we really want to use that GPLed code, we'll GPL our end product as well. If we really want to use that ADCL code, we'll pay the license fee and avoid the lawsuit." In both cases, the minute the terms and conditions of the license become too onerous, the integrator goes "I'm better off building the whole thing in-house". There are projects that don't go with GPLed code for that reason. There would be projects that would avoid ADCLed code for that reason. I think the key to success would be to make it known that the ADCL applies *unless* you cut a separate deal with the author(s). Then its up to the author(s) to decide if its worth it to go with an alternate license for this one particular customer. As for the complexity of collecting fees, etc? I agree. That is a problem. Some level of infrastructure would have to exist that made this as painless as possible. But remember that there are existing models for doing this such as ASCAP in the recording industry. I'd like to see the mechanisms for determining royalty percentages, etc. and the mechanisms for collecting/disbursing fees. I think there are a lot of questions that need to be answered and resolved before the ADCL is something practical. I just think that the *concept* is worth investigating and seeing if something could be made to work. > > (There were three of us who had the > > notion that a statistics package would be a good place to start > > I'm curious - why? I'd start with the stuff that several others have put > into their standard libraries - look at the C++ standard libraries, the Java > standard libraries, what's ended up in libc, and take what's common that Ada > doesn't do well. I'd also look at the Ada libraries already written, and the > common points from them. I don't think a statistics package would come up #1 > in that list. > Lots of reasons: 1) The three of us that worked on this all had an interest in statistics and could have made use of the statistics code that resulted. 2) I rather felt that the whole group was spending lots of time arguing over the data structure-ish stuff and didn't want to get bogged down in that. My personal reaction was to think: "O.K. I'll go take on this niche that the rest of the group doesn't have as much interest in. We will come up with something that we agree looks like "A Good Start" The rest of the group will be presented with it and its a done-deal. No point arguing over it - there it is and it works. Why not accept it? 3) A lot of the library stuff you'll see with other languages (C/C++ being big examples) are either to interface to OS features (not suitable for a cross-platform Ada thing) or to make up for the crippling deficiencies of the other languages (Hey? What do you say? Let's cross-post this to C/C++ newsgroups and start another flame war! :-) Ada didn't need de-crippling features. Any library should seek to extend the usefulness of Ada and offer things that didn't exist for other languages. Statistics seemed to be a natural outgrowth from the Ada.Numerics stuff. (Maybe not as generally useful as a square root routine, but why not have it?) 4) BTW: If you look at what sort of "standard libraries" come with C or C++ you'll discover that there really isn't much. What you get is some major implementer providing a bunch of libraries that may or may not be common to other implementations. So almost *anything* that Ada did to provide a "Standard" set of libraries (at least something that all significant implementations for general purpose computers supported) would be ahead of the game. (Java might be a notable exception - but that starts the debate about "Standard Java" not being anything but "Sun Java" - one implementer, one library.) I agree that stats wouldn't be the #1 item on the list - that ought to be some tree of data structures code. Other possible branches would be commonly used data types that Ada may support but doesn't necessarily provide all the useful functionality - things like dates/times with different string formatting, temperatures, various scientific units and conversions, etc. The branch that I had an interest in (and thought would at least rank highly with a large segment of programmers) would be mathematics. Why not support statistics, probability, vector & matrix math, etc? All this stuff exists - but there isn't a "common" interface. (Same problem arose with Ada83 - no math functions under the argument that everyone can roll their own. The complaint was lack of portability because each vendor supplied a slightly different interface.) Don't you think there might be a lot of people who might look at Ada and say "You know, I've heard all sorts of bad things about this language and I don't like (insert complaint here) about it, but gee! Look at all that statistics code I get with the compiler and can just go off and use. It sure buys me lots of leverage in my problem domain... and I don't get it automatically with my favorite single-character-language++" > 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/