On Wed, 1 Mar 2017, Henry Bent wrote: I openly used a profane word referring to bovine excrement as my opinion of this concept of "abandonware". It's just warez, plain and simple. -uso.

My understanding is that System V source of any sort is not legal to distribute. I believe that source exists and has been archived for at least some variants of SVR1, SVR2, SVR3, and SVR4. -Henry On 1 March 2017 at 14:18, Arthur Krewat <krewat(a)kilonet.net> wrote:

Sure, I was referring to the AT&T source / porting bases. That being said, I have seen numerous versions of Solaris source in the wild. -Henry On 1 March 2017 at 14:29, Steve Nickolas <usotsuki(a)buric.co> wrote:

On Wed, Mar 1, 2017 at 12:49 PM, Random832 <random832(a)fastmail.com> wrote: Their paid-up perpetual license that granted them the right to do that? Warner

Below On Wed, Mar 1, 2017 at 2:29 PM, Steve Nickolas <usotsuki(a)buric.co> wrote: ​Not a lawyer and don't play one TV or anywhere else.... Some thoughts... 1.) UCB Regents Position per AT&T/BSDi/UCB - anything through 32V is public domain (see groklaw) 2.) All of Sun & IBM, bought out source licenses from AT&T with rights to do anything.... IBM is based on the SVR3 license, Sun on SVR4 3.) IBM's license is the basis for the OSF/1 license 4.) HP independently eventually gets is own bought out license, but I'm not sure what it's based [need to google the old UNIGRAM/X or the like] 5.) Sun takes SVR4 in and starts to add "Solaris features" to it (not going to argue percentages here for the moment). 6.) Sun open sources this code base... Now some questions.... the SysV linage was made public by step 6. I have seen argument that anything through SVR3 is public because of the actions of IBM, HP, and SUN when the code was bought out; but I have not seen a definitive action like step 6 that infer all of SVR3 was public.

On 1 Mar 2017, at 21:28 , Clem Cole wrote: I think the USL lawyers feared that a jury might side with the Regents' position and therefore preferred to settle. Making the settlement secret was a clever idea and if it wasn't for Linux happening might have succeeded. Even if the position taken by the USB Regents would not hold up in court, than anything through to and including 32V is still available under the BSD-style license granted by Caldera Inc. (see http://www.tuhs.org/Archive/Caldera-license.pdf). It was later established in court that Caldera did not hold copyrights to Unix, but that Novell did at that time. However, Caldera was the licensing agent for Novell and had broad rights to grant licenses (and collect license fees as applicable). Novell had the right to overrule Caldera if it felt such was necessary. It did so when Caldera revoked IBM's license. It did not overrule the "ancient unix" license, even though it was aware of it. Renouncing it 15+ years later probably won't stick. Caldera (later renamed TSG) went bankrupt around 2011 and I'm not sure where the licensing agency went - perhaps it lapsed. Novell was acquired by Attachmate in 2010, which was acquired by British firm Micro Focus in 2014. Presumably they now hold the copyrights to the Unix source code. If so, perhaps they can be convinced to extend the BSD-style license to later versions, e.g. extend it up to SysV/R4. Note I'm not a lawyer and just expressing opinion. Paul

Web server IP comes back as Russia. On 3/2/2017 1:50 AM, Cory Smelosky wrote:

Thanks for the link ... archiving commencing. On 3/3/2017 10:29 PM, Warren Toomey wrote:

Yes, the AIX code looks nothing like SYS V. It's been 20+ years since I did a lot of work in AIX, and most of my work was in networking, external pagers, and NFS, and even there you could see it was different (although much of the NFS was clearly the Sun reference code, one giveaway being the Sun copyrights in it :-) I always thought it was an interesting code base -- they seemed to get preemptability right from the start, for example. As it was explained to me, IBM did a full implementation from manuals of both the kernel and the commands. There were lots of little weirdnesses in the commands. mkdir -p, for example, would give you an error if the directory existed -- they got the creation of the tree right, but the error wrong. There were tons of these little gotchas in the commands and it's one thing that made NTP and Condor, for just two examples, a real chore on AIX. I visited the now-closed IBM Palo Alto center in 1991, and they told me an interesting AIX story. Seems to that point, on the mainframes, AIX had run under VM. The native port was either starting or soon to start, and there was some question about channel programming -- mainly, if the people who really knew how it worked were still at IBM, or even still alive. I guess they worked it out, however ;-)

On Mon, Mar 6, 2017 at 11:20 AM, Joerg Schilling <schily(a)schily.net> wrote: ​I can say for a fact that is not how it was. AIX was a port starting with AT&T code originally targeted to run on DEC and Intel Systems. As I said previously when I ran down the history of AIX, the developers had AT&T licenses. As I was reminded in an off line discussion with one of the IBM guys when I was checking to make sure, ISC did the original 386 port for all of AT&T, Intel and IBM (one port - 3 checks). ISC also started the AIX port, with a number of the folks moving to LCC which was a step I left out in my previous email sorry, since it was implied when I said they started with that AT&T 386 stuff (which AT&T got from ISC). Bottom line.... it was not a rewrite, it was always a port. One of the issues that I think many people from the outside looking in, do not fully understand is that many firms struggled with was how difficult it was/is to keep things current (BTW: Linux struggles with today just as much as UNIX ever did - just less marketing $s being spend - it is very hard problem). Companies like DEC, HP and IBM start working with one version of the kernel or worse yet, the command system and enhance it as they need. But time moves forward and their version and the rest of the world start to become different (branch/fork). Linux has been mostly able to keep the kernel the same, but not the command system. Anyway, the question is how do keep your "branch" current. Not only do you have to compete with other "vendors" -- you also have we now call the FOSS community creating and enhancing the tools, so you want to pick up those new tools and or some if not all of the enhancements to those you already have. Plus those enhancement are likely to conflict with you own. Its a struggle and the bigger the firm, it seems like the harder time they have doing it. General you start with one, and just keep folding in. Rarely do you swap out. Both DEC and HP used OSF/1 as time to swap out the command system. DEC swapped out the entire kernel, HP did not. Interestingly enough, IBM, who's license OSF was using, IIRC did not use either part from OSF in it;s entirety, but instead took things back piece by piece. Anyway, I think AIX as a whole was an example of that. I'd have to check with some of my old LCC coworkers about what versions of the command system was used to start with for AIX. I never directly worked on that project so I'm personally not sure. My guess it would have been PWB III time frame was the SCCS starts, with a lot of BSD injected because of the University focus, whatever was kicking around Yorktown, plus whatever ISC had, plus whatever LCC/UCLA had - oh yeah and originally it had to run both on 386s and 360s, so the code user space had some stuff in that was "different" from what you saw on Vaxen. IBM Marketing (just like DEC and HP marketing) technically decided what was in or out, not the techies (although at DEC we were probably a little more devious). But at DEC not matter what was in the code - the "SPD" was the final statement - and that was own by Marketing. I'm pretty sure AIX worked similarly.

On Tue, Mar 7, 2017 at 1:52 AM, Angelo Papenhoff <aap(a)papnet.eu> wrote: ​I'm not saying it is not possible as it there was certainly precedent at other places.​ As I said, DG did a ground up rewrite for their new kernel at one point. DEC and HP switched to OSF/1 (aka CMU Mach). And I also know that the AIX base was originally considered for OSF/1 but was rejected in favor of OSF/1. I also have not knowledge of a ground up rewrite and I did work with a number of IBM guys for a long time and my firm did a lot work for IBM. I really think if they had completely rewritten it, in the manner of DG and say Stratus; then there would have been much more notice in the community at large. Part of why I am a little suspect is why would they have invested in a rewrite if they already had something that worked for their systems (which they did) -i.e. the business reason behind it and remember IBM was very much driven by their businesses. Stratus needed fault tolerance, so a new kernel was a requirement for them. DG, DEC were all trying to play catch up with Sun and were trying to use their new kernels as way to do so quickly. Thus, I suspect this is an area where large sections of the AIX kernel were replaced, similar to the way BSD evolved, but can not say for sure. You would need some of the folks from Austin to chime in. I did check with some from folks from IBM and LCC at the time and validated as one of them said to me "your memory, is pretty much the same as mine." BTW: even if they did do a whole kernel swap at between version X and Y - that would beg the questions of incompatibility. They would have had the earlier AT&T/BSD code/semantics - and would have had to specifically break it (as BSD 4.2 did in couple of cases). While possible, again, I do have memories of my brothers and sisters at LCC working on the IBM projects with a load of compatibility tests (many which we had written for them). That's not to say, there were not times when the IBM folks interpreted things differently. I do have memories explaining PDP/Minicomputer-isms to the more mainframe thinking folks. But Clem

Channel programming wasn’t really at the time. Maybe the guys at PASC didn’t know, but it was available. Never saw anything written in PL/I there. Now the other 370 mainframe stuff that wasn’t in assembler was written in PL/S which was sort of PL/I but not really. They used it for TSO (suitable for kicking dead whales down the beach) and MVT (multiprocessing with a variable number of turds, part of the virtual toilet access protocol). Of course, the RS/6000 AIX was completely different and somewhat weird. I might buy it being written in PL/S. I spent a lot of time over the years either pursuing security vulnerabilities or patching up ones that I had found. IBM loaned us an RS/6000 and didn’t give me the root password. This took me a while to figure out. I found however that if you turned the key on the front to the service (wrench) position, it would boot up in a canned “diagostic” program. I poked at this a while until I realized that the help program just spawned more and I could shell escape out to a root shell. From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dan Cross Sent: Monday, March 6, 2017 11:21 AM To: ron minnich Cc: TUHS main list Subject: Re: [TUHS] Source code abundance? On Mon, Mar 6, 2017 at 10:57 AM, ron minnich <rminnich(a)gmail.com> wrote: Yes, the AIX code looks nothing like SYS V. It's been 20+ years since I did a lot of work in AIX, and most of my work was in networking, external pagers, and NFS, and even there you could see it was different (although much of the NFS was clearly the Sun reference code, one giveaway being the Sun copyrights in it :-) I always thought it was an interesting code base -- they seemed to get preemptability right from the start, for example. As it was explained to me, IBM did a full implementation from manuals of both the kernel and the commands. There were lots of little weirdnesses in the commands. mkdir -p, for example, would give you an error if the directory existed -- they got the creation of the tree right, but the error wrong. There were tons of these little gotchas in the commands and it's one thing that made NTP and Condor, for just two examples, a real chore on AIX. I visited the now-closed IBM Palo Alto center in 1991, and they told me an interesting AIX story. Seems to that point, on the mainframes, AIX had run under VM. The native port was either starting or soon to start, and there was some question about channel programming -- mainly, if the people who really knew how it worked were still at IBM, or even still alive. I guess they worked it out, however ;-) I once heard that some version of AIX was actually implemented in PL/I. I strongly doubted that, and no one's mentioned it so I assume that's apocryphal? It would be so distinctive that I can't imagine someone NOT mentioning it if it were the case. - Dan C.

I believe we have the originator of that quote on this list. Steve? -----Original Message----- From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dave Horsfall On Mon, 6 Mar 2017, Ron Natalie wrote: Now there's an expression I haven't seen for many years.

On Tue, Mar 07, 2017 at 10:13:31AM -0500, Ron Natalie wrote: Personally, so long as it wasn't garbage code, I've always been sort of stoked to stumble across my code in strange places. It's fun to think that people found it useful. There was a period of time, not sure if it is true now or not, that my rewrite of dd(1) was in use at all the disk drive companies. It has a lot of tweaks in it for benchmarking, it can do random iops, report bandwidth or latency, write a known pattern, verify the pattern, etc. Nothing earth shattering but useful enough that when I talked to people working on drives they'd mention it when we were talking about performance stuff. Neat. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Mon, Mar 6, 2017 at 8:21 AM Dan Cross <crossd(a)gmail.com> wrote: I spent about 6 years working with IBM and U. Penn on AIX and nothing of that was ever mentioned by anyone. It sounds like a myth. ron

On 6 March 2017 at 13:00, ron minnich <rminnich(a)gmail.com> wrote: Also, they would have used PL/S or PLMP or somesuch (https://en.wikipedia.org/wiki/IBM_PL/S #6-). Interesting, over the years, IBM has used numerous languages for their various OS systems (http://dl.acm.org/citation.cfm?id=226253 that, granted, has no UNIX in it). N.

Can't speak for the *source trees* them themselves more than I have already, as they came from all over - BL Research, USL, IBM itself, ISC, LCC, UCB, CMU, MIT, etc...; but IBM negotiated a very extensive *SVR3 license* with AT&T and and marketed it primarily an System V based system with "BSD & IBM specfic enhancements". This license agreement was the basis for AIX shipments as well as all OSF shipments. While other places covered it, if you google around for articles from "Unigram/X"(Maureen O'Garia's crew) in the years of 1990-2000 in particular you should find a number of articles that described the transactions and how it effected the "Unix Industry." On Mon, Mar 6, 2017 at 10:33 AM, Angelo Papenhoff <aap(a)papnet.eu> wrote:

On Mon, Mar 6, 2017 at 5:29 PM, ron minnich <rminnich(a)gmail.com> wrote: ​Yes - they diverged at one point and the System/38 guys diverged again. Picking things up from both lines -- I was telling the story some what amusing story the other nigh about. the legal time team in Rochester, MN being quite different than NY. One thing you learn after having IBM has a customer, is that they were N different companies, and each had their own cultures. It could be quite trying for a small firm like LCC. Our external legal counsel once said, "for such a small firm, you guys have really interesting legal issues." But at that time, LCC was putting things in AIX, Ultrix, Tru64, HP/UX, DG/UX, Prime-ux, Intel, AT&T and a host of others. It was kinda neat setting everyone's dirty laundry though.. you learned a lot. Clem

Steve Johnson wrote: Coherent?

I'll bet anything this was Coherent, I remember the same story, I think Dennis was involved as well. On Mon, Mar 06, 2017 at 03:44:32PM -0800, Steve Johnson wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Mon, Mar 06, 2017 at 03:32:41PM -0800, Cory Smelosky wrote: Dennis told a story about doing this with Coherent: https://groups.google.com/forum/#!topic/comp.os.coherent/syYwL-GZ15U Warren

On Mon, Mar 6, 2017 at 5:59 PM, Clem Cole <clemc(a)ccc.com> wrote: ​I left out Solaris and SunOS too. And BTW: Being lucky enough to have hacked on the kernel of almost all of the majors at one time or another, I've been asked an interesting question. Which was the best to work on.. they were all different is the best answer, I give. But the fact is that DG was a source licensee but they did a full kernel rewrite starting I want to say in the late 1980s, early 1990's to build a scalable SMP. It was probably the easiest of all the kernels I ever got to hack on. Very clean, well documented and the locks were easy to understand.​ We did a study for DG to TNC into it, be they never pulled the trigger. We quoted it faster than any other port, because our experience had been that everything we had done on DG/UX had gone so smoothly. But we'll never know. They died shortly after the study was finished, which was a shame. I've sometimes wonder what happened to that IP. It would be interesting to compare it to OSF/1, which was probably the other very cool kernel I hacked on extensively for both Intel and later DEC of course. DG/UX was not quite as modern as Mach from a standpoint of things likes "ports" or being a uKernel - but as a pure well documented and easy to understand SMP UNIX kernel it was hard to beat. I did do a little work with Chorus and still have the doc set, but never worked with enough to have an opinion of how good it was. It showed promise and I know the UI/AT&T guys had hoped to go there at some point. Larry's described Solarius pretty well and my experience match his, but I always thought that the locks were madness IMO - so easy to get wrong. SunOS was a lot simpler and as Larry has said was pretty elegant for what was there. HP/UX was pretty darn bullet proof. The HP folks worked on fault tolerance got rid of panics more than other other UNIX we say, which was pretty amazing, but it was not the easiest kernel to mess with. We did manage to splice the vproc layer and TNC in it and we had a lot of fun with process migration. Its too bad that never shipped. Again, I've wonder about that IP too. Clem

My recollection of reading Groklaw way back when is that TSG had hired "a team of MIT deep divers" to do source code analysis, but I don't recall their methodology ever being disclosed. I do recall some sort of sharding tool being proposed by the Linux' defenders (Eric Raymond?). From memory, the idea was to first parse the source into a normalized form to abstract away white space and variable naming. Then the tool would shard each normalized file into slices of 3 lines and compute a SHA[?] hash for each slice. Finally it would identify hash clashes and figure out if there were ranges of lines with clashing hashes. Human inspection could then identify whether the original lines involved looked like a case of copied source code. I do not recall that this tool was ever used or even built. On 6 Mar 2017, at 17:19 , Jason Stevens wrote:

On Tue, Mar 07, 2017 at 12:19:09AM +0800, Jason Stevens wrote: Eric Raymond wrote a comparison tool. So did I: http://minnie.tuhs.org/Programs/Ctcompare/index.html That's what I use to build the similarity lists on the Unix Tree. Cheers, Warren

On Mon, Mar 06, 2017 at 12:17:44PM -0800, Larry McVoy wrote: [ I answered Larry by private mail too early this morning, and interpreted his question incorrectly. I'm awake now. ] There was slightly more 32V code in Net/2 that the UCB folk had found, but this was still negligible and could easily have been rewritten. The list of results is at: http://minnie.tuhs.org/Programs/Ctcompare/Ctf/32Vkern_vs_Net2kern.txt Warren