quote:
Pat might want to comment on it himself. His home page site notes the following:"TIF compressed LZW format needs a UNISYS license available on option."
"Writing to GIF compressed format required a UNISYS license available on option."
If he has exposure to the issue suffcient enough to have made a decision on that, then he might be able to offer some comment on the code he posted as to whether it is Public Domain or not.
I, also, would like to know the correct status of the code. Copyright issues are really messy when folks get unhappy about them. Further, it's easier to get in a mess over them than one might think. Even using the 'standard' examples in the PB 3.5 suite, appears to me to be an issue considering that they are all prefaced with something like:
' Search and Replace Utility
' Copyright (c) 1995 by PowerBASIC, Inc. All Rights Reserved.
That means EXACTLY what it says. Have you ever thought of that? It's the reason I haven't used anything of it. Technically, neither I nor you, nor anyone else can, without his expressed consent! Maybe I've missed something, but, to be precise, I can't find anywhere in the docs where it expressly gives someone the right to use the source, even though it looks, on the surface, that you ought to be able to do so, since they were furnished as examples in a oroduct you licensed for use!
No, I'm not a lawyer.
Nor, do I want to have to hire the services of one over the defense of this kind of stuff. Nor do I wnat to fuss with the Feds over this kind of stuff either. Thus, unless plainly marked otherwise, if it says "no" in the body, I take it to mean it means, "no."
Just because they are furnished as examples, doesn't, to me, for example, legally mean they, legended as such, are a part of the compiler tool you purchased the right to use when you did that. Unless they are expressly defines so somewhere else, "no" means "NO."
In the case of the code that Pat furnished, where he said:
"' LZW (like) code converted to 32-bit by Patrice Terrier"
I'd, perhaps like to use it! Since his site notes awareness of the Unisys issue, I hope he may respond to the comments, but I'll also, grin, understand if he comes back with something like 'caveate codor.'
The UNYSIS site is like stepping in a tar pit.
quote:
Thanks Greg and Pat both.The pointers to the URL's and the entire discussion were valuable and should help a lot of folks. For me, it is helping to, perhaps, resolve the questions of what to do about compression and encryption of medical record data, both for pure storage and transmission. It, perhaps, wasn't a real factor ten years ago; it's really turning nasty now.
Ten years ago we had 31 blank areas of a HCFA1500 form for a bill. Then came UB-92, with fixed-length strategy, 192 byte fixed blocks and 'specialty' de-blocking - about 8K-16K per record. Now comes AMC-X12 with over 900 defined fields! What cross-walkable fields there are to the UB-92, are about double the max size of the UB-92's corresponding ones and ... although labeled as a 'transmission standard', are totally variable length! I believe those fields go somewhere else in the scheme of things besides just -transmission-. 
Yeah, and the <:> mark is a delimiter in the records!!! Oh well.. 
You could submit about six things for which to get paid on a HCFA-1500 at one time. The max 25-50 things payable at once, on a UB-92, have expanded, as of June this year here in at least one venue in Texas, to 250 at a single billing! UB-92 use specialty records, such as just the ambulance part, for example, meant that only that one part, perhaps, needed to be stored, of old, but now, the push is on for what is known as 'unified billing.' A record now has to have space for and pointers to everything from drugs, diagnoses, procedures, ambulance ride - todos!
As well, the real questions of right to access and encryption of data are four-square in front of us. Compression and Encryption are now, to my way of thinking, taking center stage.
I had about a 45 minute conversation with Dr. Tom Shope, head of the committee on software for the FDA in late October, I think, in 1996, just from pure recall without going to the records here. As well as a lot of other very good advice, he noted that FDA would not stand for any other than lossless compression.
As a small fry, he advised I stay away from any software development which was capable of being used to directly treat or take data from a patient or be automatically included in or could automatically be made a part of a permanent medical record without the decision of a qualified medical person putting data there! Such coding, per his advice, constitutes a medical device. I've followed that advice.
So said, at some point, in that compression was in a lot more venues than we would think, I would be surprised to see that even such things as modems, networks, would be licensed for medicine, in the future! They all play compression games! All forms of software which offered compression would, if they touched medicine, be eventually licensed as such by FDA. I could not get him to tell me any more than, "Watch the Federal Register", for how to determine the progress of that vector by FDA. He said leave the compression deal, networking, to others
Per his note relative to these direct-action and compressed goodies, this meant that EVERYTHING in the program from the operating system, through the assemblers, compilers, and program code, would have to be proofed and documented for accuracy for every single line of the code! The comment was that some sort of certification program like ISO-9000 would likely be acceptable. Where code actually takes the part of un-monitored human direction, that's what the rule really was and is directed at. If one wants to stay out of the soup, make sure a human makes the decisions. OK, I've tried to follow that.
However, hardware and software are expanding in scope and complexity even faster now than they were several years ago. Looks like to me the line between a qualified medical professional's OK and what goes in and out of a record by computer and software control is blurring fast. Six or seven poor souls whom died in Tyler, Texas a number of years back, over what went wrong in a generic computer program sparked all this. Dosages in a cyclotron run for treating their cancer got botched, so I understand, just because the program reached different results with and without a numeric co-processor aboard. They were grossly over-radiated and roasted alive.
To focus this in today's world, general records and compression...
Paul Harvey, in his commentary the other morning, said that he thought we could stop Medicare fraud if every doctor had to personally sign every claim for Medicare payments! Someone should send him the now over 3900 pages on AMC-X12 which one needs to understand just how - "transmission" of a claim get paid ... $35 for a visit! Most of it is all empty space, but yet, if, as they are now insisting, that, DAILY billing is necessary, and your poor Mother has 15 different meds daily, we can't even get all of that in one invoice per month!
Yes, AMC-X12, the NPRM for final ruling published in June of last year, is upon us. The notice for public comment was over in just 30 days, on July 7, 1998! The data set is so huge that, at least, to me, the need somehow, for internal compression is upon me. Though I've, I think, managed to get the whole UB-92 into one huge less-than-16K UDT with some 1200 discrete variables, on the way to somewhere for a date with the even larger AMC-X12 crosswalk; most of it is still empty space. Even though we've, so it seems, moved from no more FIELD statements to only such things as UDT's in WIN-xx, for file data write/read use, AMC-X12 will be a *LOT* more empty space than a mostly empty UB-92 for 95% of all records. Pure AMC-X12 doesn't, to me, seem anything appicable to any of the way any of this WIN-xx or generic file I/O stuff has gone, but then I don't claim to be any kind of expert in this stuff. Looks to me if little folk are still able to be involved, it has to be a compressed and delimited storage affair and we are still, right back to letting the operating system, or an embedded such creature like it, do the work!
Choosing a compressive technique to handle the storage might be a VERY important decision, right about now... It could have serious long term effects in many disciplines for one's software produced.
Choosing a form of compression now that has roots in an open-source forum and public proof-of-losslessness seems an important decision. If one is going to be able to avoid royalty payments on all this and, maybe some day get paid for the work, one has to think carefully about what has surfaced here, together with the advice Tom gave me a few years back. The posts and thread here seem very relevant to that to me.
The concepts here should be of valuable to others.... regardless of what may be their interest in serving customers with software.... With what I, somewhat jokingly suggest next aside, taking care of customers and making things easiest for them is the only way to really build and stay in business. Well, except that sometimes I think the only business of which the customer ain't always right, is the business of Government, but .. sigh ... that's life!
Thanks.. to all for the help...
PowerBASIC Forums
UBBFriend: Email This Page to Someone! 
posted March 21, 1999 02:24 PM
