geoff@desint.UUCP (Geoff Kuenning) (01/03/85)
In article <1276@orca.UUCP> andrew@orca.UUCP (Andrew Klossner) writes: >> "I have heard the claim (and it makes sense to me) that SOURCE >> code put out by yacc is proprietary, since it contains >> /usr/lib/yaccpar. > >In 1982, it was the official legal position of AT&T that object code >from yacc is proprietary. Mind you, I'm not volunteering to be a test case, but my layman's legal opinion is that AT&T cannot claim ownership of yaccpar, /usr/include/*, /bin/lint and /bin/spell, and anything else that you can 'cat' at will. My reasoning is as follows: (1) AT&T has traditionally used trade secret law to protect UNIX. All UNIX licenses include a requirement that anyone given access to the source of UNIX sign a nondisclosure agreement. (2) AT&T has never tried to claim a copyright on the source code of UNIX. This is keeping with the best legal advice of the late 70's, which said that copyrighting involved publishing which is antithetical to keeping something secret. There are copyrights on AT&T's *printed* documentation, but there are none in the source code. Nor are there any in /usr/lib/yaccpar (I just looked). My /usr/include stuff has copyrights from UniSoft, but none from AT&T. Since all of this stuff has been around for over 1 year, I conclude that it is now in the public domain (from a copyright point of view). (3) Since /usr/lib/yaccpar is not copyrighted and is not patented, AT&T's only legal protection is trade secret law. But the most basic element of that law is that the information must be kept *secret* by restrictions and contractual agreements. Over the years, thousands of unprivileged users have been given unrestricted access to /usr/include and all other cat-able files. So where is the secret? Thus, AT&T would seem to have no legal recourse against people who use publicly-readable files. In fact, trade secret law doesn't prohibit reverse engineering, either. I have seen a lot of recent contracts that explicitly prohibit disassembling the code involved. Since at least the older AT&T contracts do not cover this possibility, it is probably also legal to disassemble any binary that has world read permissions unless you are covered by a more recent contract. This is not to be construed as advice to go blithely stealing AT&T code just because it's in /usr/include. I would at least check with a real lawyer first. But I am eagerly awaiting the first test case. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
henry@utzoo.UUCP (Henry Spencer) (01/06/85)
> (1) AT&T has traditionally used trade secret law to protect UNIX. All > UNIX licenses include a requirement that anyone given access to > the source of UNIX sign a nondisclosure agreement. I don't recall the exact wording, but I'll be very surprised if it makes any distinction between source and binary for non-disclosure purposes. Every byte of software supplied by Bell is covered, source or not. > (3) Since /usr/lib/yaccpar is not copyrighted and is not patented, AT&T's > only legal protection is trade secret law. But the most basic > element of that law is that the information must be kept *secret* by > restrictions and contractual agreements. Over the years, thousands of > unprivileged users have been given unrestricted access to /usr/include > and all other cat-able files. So where is the secret? Anyone who has granted access to this stuff without imposing a non-disclosure requirement as a condition of access is in violation of their Unix licence, and AT&T could sue them for their shirts over it. > Thus, AT&T would seem to have no legal recourse against people who use > publicly-readable files. Bell-supplied software is not supposed to be made publicly-readable, in the broad sense of the word "public". > In fact, trade secret law doesn't prohibit reverse engineering, either. I > have seen a lot of recent contracts that explicitly prohibit disassembling the > code involved. Since at least the older AT&T contracts do not cover this > possibility, it is probably also legal to disassemble any binary that has > world read permissions unless you are covered by a more recent contract. Certainly it is legal to disassemble it, but that is Bell code you are disassembling, and it is covered by non-disclosure. My understanding is that binary-only licences still have a non-disclosure clause. Giving people only the binaries is an enforcement tactic, making it harder to steal things inconspicuously; it does not change the nature of the legal protection. Catting things == accessing them. Ability to access Bell-supplied stuff without being covered, somehow, by non-disclosure provisions => licence violation somewhere. It's as simple as that. *ALL* Unix licences include non-disclosure clauses; *ALL* Bell-supplied software -- sources, binaries, libraries, EVERYTHING -- is covered by those non-disclosure clauses. No way is any of this stuff in the public domain, legally. Whether it is in the public domain in practice is another story. Quite possibly one could argue that illicit access to Unix materials, including sources, is so common that AT&T cannot realistically claim that the stuff is secret any more. The problem is, AT&T would fight such a contention tooth and nail, and being right is not comforting when you are facing a legal battle of that magnitude and expense. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
smh@mit-eddie.UUCP (Steven M. Haflich) (01/06/85)
Re reverse engineering: a fairly detailed description of the Yacc state machine is given in at least one of the standard Yacc references -- see "man yacc" -- so the *algorithm* can hardly be called a trade secret.
ed@mtxinu.UUCP (Ed Gould) (01/07/85)
> Whether it is in the public domain in practice is another story. Quite > possibly one could argue that illicit access to Unix materials, including > sources, is so common that AT&T cannot realistically claim that the > stuff is secret any more. The problem is, AT&T would fight such a > contention tooth and nail, and being right is not comforting when you > are facing a legal battle of that magnitude and expense. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Henry's hit the nail right on the head. Most of us aren't willing to take this (probably small) risk because of the potentially enormous (probably out of business) expense. -- Ed Gould mt Xinu, 739 Allston Way, Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 (I'd rather not be parochial.)
gamiddleton@thunder.UUCP (Guy Middleton) (01/07/85)
In article <4866@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> Over the years, thousands of >> unprivileged users have been given unrestricted access to /usr/include >> and all other cat-able files. So where is the secret? > >Anyone who has granted access to this stuff without imposing a non-disclosure >requirement as a condition of access is in violation of their Unix licence, >and AT&T could sue them for their shirts over it. Are you saying that *anybody* who uses a system should be made to sign a non-disclosure agreement? I doubt that any university (with several hundred students on a typical Unix machine) could force all of them to sign any such thing. ________ Guy Middleton, Lakehead University, Thunder Bay, Ont. ..{allegra,clyde,decvax,utcsrgv}!watmath!thunder!gamiddleton
steiny@scc.UUCP (Don Steiny) (01/08/85)
> Re reverse engineering: a fairly detailed description of the Yacc state > machine is given in at least one of the standard Yacc references -- see > "man yacc" -- so the *algorithm* can hardly be called a trade secret. That's for sure! The book "Principles of Compiler Design" details lex and yacc throughly. -- scc!steiny Don Steiny - Personetics @ (408) 425-0382 109 Torrey Pine Terr. Santa Cruz, Calif. 95060 ihnp4!pesnta -\ fortune!idsvax -> scc!steiny ucbvax!twg -/
henry@utzoo.UUCP (Henry Spencer) (01/08/85)
> >Anyone who has granted access to this stuff without imposing a non-disclosure > >requirement as a condition of access is in violation of their Unix licence, > >and AT&T could sue them for their shirts over it. > > Are you saying that *anybody* who uses a system should be made to sign a > non-disclosure agreement? I doubt that any university (with several hundred > students on a typical Unix machine) could force all of them to sign any such > thing. Check your Unix licence for the exact wording, but a randomly-grabbed (somewhat old) AT&T licence from my files reads, in part: LICENSEE agrees that it shall hold the LICENSED SOFTWARE in confidence for AT&T and the other Bell System companies. LICENSEE further agrees that it shall not make any disclosure of the LICENSED SOFTWARE ... to anyone, except to employees or students of the LICENSEE to whom such disclosure is necessary to the use for which rights are granted hereunder. LICENSEE shall appropriately notify each employee and student to whom any such disclosure is made that such disclosure is made in confidence and shall be kept in confidence by him. In other words, technically you are required to tell all your students about the confidentiality requirements, and order them to comply. Also, as I suggested in the earlier message, there appears to be no distinction made between sources, libraries, include files, and binaries. It's all covered. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
kurt@fluke.UUCP (Kurt Guntheroth) (01/08/85)
Remember there is a class of UNIX(tm) users who are not routinely subject to
non-disclosure agreements, using systems where access to sources is not
typically restricted. These users are college students and professors, and
hackers who break into these systems as well.
Can AT&T make a strong claim that these sources are a secret in view of the
probability that any given software engineer could have perused them at
length as a student? Does the trade secret act deal with the legality of
some hacker breaking into a university computer, taking accessible
information, and using/distributing/publishing it? Doesn't the
non-disclosure agreement only cover non-disclosure of information you could
not easily obtain elsewhere?
Go for it oh legal eagles.
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtberry@zinfandel.UUCP (Berry Kercheval) (01/08/85)
In article <185@thunder.UUCP> gamiddleton@thunder.UUCP (Guy Middleton) writes: >Are you saying that *anybody* who uses a system should be made to sign a >non-disclosure agreement? I doubt that any university (with several hundred >students on a typical Unix machine) could force all of them to sign any such >thing. When someone matriculates at a university, most of them sign some sort of document agreeing to abide by the rules and regulations of the University, don't they? I know I did. I would be very surprised if registered students, faculty and staff were NOT obliged by this document to respect the University's contractual obligations. -- "Take this //JOB and run it!" Berry Kercheval Zehntel Inc. (ihnp4!zehntel!zinfandel!berry) (415)932-6900
dave@lsuc.UUCP (David Sherman) (01/09/85)
The questions of the /usr/include files is an interesting one. Many
of them are included in the UNIX Version 7 manual (actually included
by a .so instruction to nroff) in sections 2, 3 and 5 (e.g., stat(2)
includes /usr/include/sys/stat.h). Now, as has been pointed out, the
manual is protected by copyright rather than trade secret. If indeed trade
secret cannot exist after publication, then these files can hardly
be said to be protected by trade secret any more.
Dave Sherman
The Law Society of Upper Canada
Toronto
--
{utzoo pesnta nrcaero utcs}!lsuc!dave
{allegra decvax ihnp4 linus}!utcsrgv!lsuc!davethomas@utah-gr.UUCP (Spencer W. Thomas) (01/09/85)
In article <185@thunder.UUCP> gamiddleton@thunder.UUCP (Guy Middleton) writes: > >Are you saying that *anybody* who uses a system should be made to sign a >non-disclosure agreement? I doubt that any university (with several hundred >students on a typical Unix machine) could force all of them to sign any such >thing. All users of our machines are given accounts with the understanding that they must abide by all the rules and restrictions under which the software was acquired. Anyone violating said restrictions can (and will) lose their account. -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) <<< Silly quote of the week >>>
jeff@gatech.UUCP (Jeff Lee) (01/10/85)
> Are you saying that *anybody* who uses a system should be made to sign a > non-disclosure agreement? I doubt that any university (with several hundred > students on a typical Unix machine) could force all of them to sign any such > thing. > ________ > Guy Middleton, Lakehead University, Thunder Bay, Ont. > ..{allegra,clyde,decvax,utcsrgv}!watmath!thunder!gamiddleton Here at Georgia Tech, anyone who is given an account on the Unix(tm....giggle) system/systems has been required to sign a non-disclosure license because the source has been on the systems. The license specified that everyone who was to have access to this stuff has got to sign their firstborn male child away or look at one heck of a lawsuit (I assume). I have not heard that the same is required of binary-only licensees(sp?) which makes me wonder if reverse-engineering would be legal in that case. I do not know of any binary-only folks who require non-disclosure licenses. Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff.GATech @ CSNet-Relay uucp: ...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff.GATech @ CSNet-Relay uucp: ...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff
geoff@desint.UUCP (Geoff Kuenning) (01/10/85)
In article <4866@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Anyone who has granted access to this stuff without imposing a non-disclosure >requirement as a condition of access is in violation of their Unix licence, >and AT&T could sue them for their shirts over it. So? Does U of Toronto require literally *every* student who has ever taken a Unix course or had a Unix signon to sign a nondisclosure? If so, you are the exception, not the rule. Besides the obvious case of university students, there are also public access Unixes. I know of installations in Chicago and San Francisco. Both have 'guest' logins, and will grant a login to anyone who asks, as well. There are also several budding commercial timesharing Unix systems. I can also point out at least several cases of Unix systems which are on dialup phone lines accessible to any "cracker," and which have guest logins with no password. Several 68000 companies, for example, provide "demo" phone numbers with guest logins. (In fact, I have seen systems that don't even have a root password!). Finally, there are the commercial installations. When a TRW employee hires on, he or she typically signs a blanket nondisclosure/invention ownership document. Two or more years later, he/she is given a UNIX login. But was it made clear that this involved a specific nondisclosure responsibility to AT&T? Also, a number of AT&T customers (OEM's) have been sloppy about UNIX licenses, especially in the early days. I know of more than one 68000-based system which the owner paid cash for, legally, yet never signed a nondisclosure. My point is that, although technically you are right (all of these people are guilty of violating the nondisclosure agreement), legally AT&T has no recourse against these people. One of the requirements of trade secret law is that AT&T must make a sincere good-faith effort to maintain the secrecy of their material. My position (if sued by AT&T) would be that the number of people who have had non-restricted access to all or part of UNIX is prima facie evidence that AT&T has not taken sufficient care to restrict their trade secret. In particular (warning: I am working from rusty memory on the contract; forgive me if I blow it): (1) Many editions of the AT&T contract have not explicitly prohibited granting access to the "publicly-readable" files. I am pretty sure that I have seen contracts listing /usr/src as the only thing that must be protected as an AT&T trade secret. (2) Most editions of the contract have said nothing about who may be given logins on the system, although there is a provision that anyone who is given "access" to the *sources* (not the timesharing system as a tool or entity) must be bound by nondisclosure. (3) AT&T has been aware for some time of the existence of university students who use Unix. I suspect AT&T has taken no action to make sure that these "ordinary" users are bound by non-disclosure. (4) The same goes for public-access Unixes, which have been around for at least two years now -- plenty of time for an aggressive company to learn of their existence and write them a nasty legal letter. (5) Finally, AT&T has not (in my perception) been very aggressive about seeking out and prosecuting violators of their trade secrets. In my experience, it is normal for your average Unix wizard to leave his or her job with tapes under the arm. The last guy I worked with who had access, had tapes of V7, SIII, and BSD. All illegal, to be sure, but nevertheless AT&T hasn't made much news suing those types. Even former AT&T employees are among the violators. Note that, under US trade secret law, all of the people responsible for letting the cat out of the bag are liable for damages to AT&T. However, anyone who learned these secrets *from* those people can use them at will. So, although AT&T can sue a bunch of people for a bundle, the "secrets" are no longer AT&T's property in the sense that anyone can be sued for using them. If one accepts that Bell cannot successfully defend "trade secret" protection on their binaries/public files, many of Henry's other comments become irrelevant. >Whether it is in the public domain in practice is another story. Quite >possibly one could argue that illicit access to Unix materials, including >sources, is so common that AT&T cannot realistically claim that the >stuff is secret any more. The problem is, AT&T would fight such a >contention tooth and nail, and being right is not comforting when you >are facing a legal battle of that magnitude and expense. This is true. As Ed Gould pointed out, no wise person is going to volunteer to be a test case. But AT&T is in a bit of a bind here. If they don't fight AND WIN a test case pretty soon, the thing is going to be so open and shut that even you and I could afford to fight them off. DISCLAIMER: As before, I am not a lawyer. The legal opinions expressed herein are gleaned from layman-oriented articles and are probably completely bogus. Trust them at your own risk. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
geoff@desint.UUCP (Geoff Kuenning) (01/12/85)
In article <217@vax2.fluke.UUCP> kurt@fluke.UUCP (Kurt Guntheroth) writes: >Does the trade secret act deal with the legality of >some hacker breaking into a university computer, taking accessible >information, and using/distributing/publishing it? As I understand it, it's not an act, it's a body of law relating to trade secrets that goes a long way back (possibly to English common law). To answer your question, yes, the law deals with this quite explicitly. Most articles on trade secrets for the computer layman have covered this point (which is where I got it). The hacker is liable for the full value of the software he/she took from AT&T and published (good luck recovering, Bell!). However, anyone who acquired that software from net.sources *in good faith* CANNOT be held liable. (Good faith means that nobody on this net should try to claim that they didn't know the UNIX kernel was proprietary when it was posted to net.sources). Furthermore, once a *single* party has acquired the sources by legal means and in good faith, the trade secret is effectively gone. Poof. >Doesn't the >non-disclosure agreement only cover non-disclosure of information you could >not easily obtain elsewhere? Yes. There is a specific provision in trade secret law that prevents you from recovering if the defendant can show that the secrets were *not* acquired by any illegal means. (Note that this is not true of US military-secret law.) This is similar to the patent and copyright provisions that basically keep you from getting protection on something that's been around for 50 years unpatented or uncopyrighted. There is also a specific provision in at least California non-disclosure law (and in many fair non-disclosure agreements) that voids a non-disclosure agreement regarding any information that the student or employee knew before signing. (I presume, though I don't know, that there is an exception to the exception to handle the case where the "prior knowledge" was covered by an earlier nondisclosure). BTW, Henry is right about the AT&T (source) contract covering *everything*. However, my position is that this contract has been (and continues to be) violated sufficiently often that AT&T has no chance of claiming trade secret protection on the UNIX binaries. There are just too many people who have been given binary access on a casual basis. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
root@ncoast.UUCP (Brandon Allbery (the tame hacker on the North Coast)) (01/14/85)
> Article <185@thunder.UUCP>, from gamiddleton@thunder.UUCP (Guy Middleton) +---------------- | In article <4866@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: | >> Over the years, thousands of | >> unprivileged users have been given unrestricted access to /usr/include | >> and all other cat-able files. So where is the secret? | > | >Anyone who has granted access to this stuff without imposing a non-disclosure | >requirement as a condition of access is in violation of their Unix licence, | >and AT&T could sue them for their shirts over it. | | Are you saying that *anybody* who uses a system should be made to sign a | non-disclosure agreement? I doubt that any university (with several hundred | students on a typical Unix machine) could force all of them to sign any such | thing. At which point we can drop Unix and its paranoid owner, AT&T, in the dungheap and go for something sane. Maybe if we push this, AT&T will get it together (if it CAN)... --bsa -- Brandon Allbery @ decvax!cwruecmp!ncoast!bsa (..ncoast!tdi1!bsa business) 6504 Chestnut Road, Independence, Ohio 44131 +1 216 524 1416 (or what have you) Who said you had to be (a) a poor programmer or (b) a security hazard to be a hacker?
henry@utzoo.UUCP (Henry Spencer) (01/16/85)
> ... Does U of Toronto require literally *every* student who has ever taken a > Unix course or had a Unix signon to sign a nondisclosure? If so, you are the > exception, not the rule. U of T definitely doesn't go this far; certainly my installation doesn't. Thing is, if it comes to a legal battle, we are clearly in the wrong for not taking action on the matter. Note that the AT&T software licences explicitly demand that users be informed of their non-disclosure obligations; I can think of no possible defence for ignoring this part of the licence. Whether or not certain items of the software really are protected any more, a signed licence that says you agree to tell your users about the issue is hard to argue with. > ... there are also public access > Unixes. I know of installations in Chicago and San Francisco. Both have > 'guest' logins, and will grant a login to anyone who asks, as well. ... I hope they have good lawyers. If AT&T ever gets tough with them, they are in big trouble. > I can also point out at least several cases of Unix systems which are on > dialup phone lines accessible to any "cracker," and which have guest logins > with no password. Several 68000 companies, for example, provide "demo" > phone numbers with guest logins. (In fact, I have seen systems that don't > even have a root password!). Same comment: I hope they have good lawyers. We got rid of our "guest" account as soon as we thought about this for a moment. The combination of (a) dialups, (b) a no-password account, and (c) access to AT&T material strikes me as an open-and-shut case. > My point is that, although technically you are right (all of these people are > guilty of violating the nondisclosure agreement), legally AT&T has no > recourse against these people. ... Mmm, really? Stipulating that AT&T has technically forfeited trade-secret protection by not being careful enough, that still leaves that nasty little licence that your institution signed. Absence of trade-secret protection would mean that the things are available for general use, but I strongly suspect that a signed agreement remains a signed agreement, and deliberate violation of it remains grounds for a lawsuit. Certain clauses of the agreement would become pointless, but that does not necessarily make them null and void. This is the sort of thing lawyers get rich on. > ... all of the people responsible for letting > the cat out of the bag are liable for damages to AT&T. However, anyone who > learned these secrets *from* those people can use them at will. ... You're sure about that? My impression was that the necessary condition for use at will was that they acquired the secrets "in good faith", i.e. not realizing that they were secrets. Convincing a court that you didn't realize the Unix kernel was a secret strikes me as hard; if you know enough to know what it is, you are very likely to know its status. > This is true. As Ed Gould pointed out, no wise person is going to volunteer > to be a test case. But AT&T is in a bit of a bind here. If they don't fight > AND WIN a test case pretty soon, the thing is going to be so open and shut > that even you and I could afford to fight them off. Speak for yourself! *NO* legal fight against AT&T is open and shut if they are seriously interested in winning. In an ideal world, a simple case where the evidence was clear could be won easily and cheaply, even against a huge opponent. This is not an ideal world. We are talking about undermining the proprietary nature of Unix itself, the keystone of AT&T's assault on the software market. (The arguments that would apply to the binaries today could be applied to the sources tomorrow.) I would expect the legal warfare to last a decade and cost millions. I would also refuse to put any large bets on the outcome, regardless of how obvious the rights and wrongs are. P.S.: Like Geoff, I am not a lawyer. Consult an expert before doing anything rash. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
geoff@desint.UUCP (Geoff Kuenning) (01/18/85)
In article <132@circadia.UUCP> dave@circadia.UUCP (dave) writes: >To my mind, it doesn`t matter if AT&T still has LEGAL control over UNIX; >I think, especially with V6, they have lost their trade-secret protection. >Does this mean that we should go ahead and use UNIX without compensation >to AT&T? I think not. The lawyers, out there, might want each corporation >to abide by whatever the legal code says, but I think what is missing from >the system is a sense of "Right and Wrong"; one does not take his neighbors >automobile because he left the keys in it. Although most of us (all right, at least I) have been arguing an abstract legal point more than arguing that we can get away clean with AT&T's code, Dave is entirely right here. Furthermore, if AT&T actually loses trade secret protection for UNIX in court, who will be left to spend all that monetary muscle maintaining it and enforcing it as a standard? I think trade secret loss would probably be a loss for the community. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
jc@mit-athena.ARPA (John Chambers) (01/24/85)
Hey, haven't we sorta lost track of the original question here? As I understand it, there is a suggestion that code produced by yacc belongs to AT&T or Bell Labs or somebody like that. Exactly which corporate entity is named isn't the important question. The important question is: If I write a program using yacc (or lex), and it turns out to be a best-seller, can AT&T or some other corporate clone come along and claim all my royalties for their own coffers? Until this is settled, I don't think I'll use yacc or lex. In fact, maybe I shouldn't even be using any high-level language. How do I know that the output of the C compiler isn't the legal property of the compiler's author? Hey, anyone out there know the real legal situation? This is not a frivolous question. We're talking about us little guys having to give up all rights to our creation because we happened to use some corporation's tool to produce it. John Chambers
doug@terak.UUCP (Doug Pardee) (01/28/85)
> How do I > know that the output of the C compiler isn't the legal property of > the compiler's author? In the case if C (and most other high-level languages), the output of the compiler isn't usually considered to be property of the compiler company. After all, they would be hard-pressed to show that your object code duplicates, or is a translation of, their compiler. On the contrary, you can show relatively easily that it is a translation of YOUR source program. BUT!!!! High-level languages almost always have an object-time library associated with them, and direct copies of subroutines from this library ARE linked in to your object deck. Almost all compilers come with a prohibition against commercial sales of programs which were linked with their object libraries! A software house that I once worked for sold a package which was written in IBM OS/370 COBOL. Because the COBOL compiler being sold by IBM is a copyrighted and proprietary package, and it relies heavily on the subroutine library, we had to go to GREAT pains to stay legal. Back before the courts ordered IBM to "unbundle" software, they did have a COBOL compiler which was public domain. So we had to get a copy of that, even though it was 15 years out of date, produced crummy code, and was full of bugs. A company that I worked for recently was developing a package for the IBM PC using C. They chose Computer Innovations' C compiler over the more common Lattice compiler because of one thing: Computer Innovations explicitly authorizes (in writing) sale of programs containing modules from their subroutine library, without requiring notification, permission nor royalty. Copyright infringement on compilers' subroutine libraries IS taken seriously. -- Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug
garys@bunker.UUCP (Gary M. Samuelson) (01/30/85)
> > How do I > > know that the output of the C compiler isn't the legal property of > > the compiler's author? > > In the case if C (and most other high-level languages), the output > of the compiler isn't usually considered to be property of the > compiler company. After all, they would be hard-pressed to show > that your object code duplicates, or is a translation of, their > compiler. On the contrary, you can show relatively easily that > it is a translation of YOUR source program. > > BUT!!!! High-level languages almost always have an object-time > library associated with them, and direct copies of subroutines > from this library ARE linked in to your object deck. Almost all > compilers come with a prohibition against commercial sales of > programs which were linked with their object libraries! Let me see if I understand this: If a source statement which I write is turned into several lines of machine code, which is inserted in line, then the machine code is mine, but if my source statement is turned into one or more lines of machine code which call a subroutine, then I can have the call, but not the called routine. What's the difference between a library routine, which becomes part of my object module in response to my source code, and an inline routine which becomes part of my object module in the same way? The source for both routines was written by the compiler vendor; why do I own the object for one but not the other? (Note that I said object; if the vendor claims right to the source of the library, that's fine.) In fact, I don't even know when I'm calling a library routine and when I'm not. If the target machine doesn't have instructions for 32 bit integer arithmetic (e.g., the Z80 and the M68000), then the binary operators '*' and '/' produce calls to library routines. Sounds like the story I heard about a man who was willing to let his neighbor use his lawn mower, only on condition that the neighbor couldn't remove it from the premises. Gary Samuelson ittvax!bunker!garys
ndiamond@watdaisy.UUCP (Norman Diamond) (01/30/85)
> In the case if C (and most other high-level languages), the output > of the compiler isn't usually considered to be property of the > compiler company. After all, they would be hard-pressed to show > that your object code duplicates, or is a translation of, their > compiler. On the contrary, you can show relatively easily that > it is a translation of YOUR source program. > > BUT!!!! High-level languages almost always have an object-time > library associated with them, and direct copies of subroutines > from this library ARE linked in to your object deck. Almost all > compilers come with a prohibition against commercial sales of > programs which were linked with their object libraries! > > Copyright infringement on compilers' subroutine libraries IS taken > seriously. > -- > Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug Why not supply your program's OBJECT code then, and tell your customers to link it on their machine with their licensed library. However, that doesn't quite take care of YACC yet. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
ron@celerity.UUCP (Ron McDaniels) (01/31/85)
In article <305@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes: >> How do I >> know that the output of the C compiler isn't the legal property of >> the compiler's author? > >In the case if C (and most other high-level languages), the output >of the compiler isn't usually considered to be property of the >compiler company. . . . . . Scratch "usually". If I buy a meat grinder from you and put my steak through it to make hamburger (assume a low quality cut :-), the hamburger doesn't become yours just because you manufactured the meat grinder. If I make a sandwich from the hamburger with your bread and mayo, then the sandwich isn't completely mine. Well, it makes sense to me!! :-) Ron McDaniels CELERITY COMPUTING {decvax || ucbvax || ihnp4 || akgua || philabs}!sdcsvax!celerity!ron
henry@utzoo.UUCP (Henry Spencer) (02/03/85)
> What's the difference between a library routine, which becomes > part of my object module in response to my source code, and an > inline routine which becomes part of my object module in the > same way? The source for both routines was written by the > compiler vendor; why do I own the object for one but not the > other? (Note that I said object; if the vendor claims right > to the source of the library, that's fine.) You don't own either one. The object code for the inline routine is merely a translation of the source; translation does not affect ownership in any major way, I believe. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
spaf@gatech.UUCP (Gene Spafford) (02/08/85)
> Article <185@thunder.UUCP>, from gamiddleton@thunder.UUCP (Guy Middleton) > Are you saying that *anybody* who uses a system should be made to sign a > non-disclosure agreement? I doubt that any university (with several hundred > students on a typical Unix machine) could force all of them to sign any such > thing. Here at Georgia Tech, for at least the last 3 or 4 years, anyone getting an account on one of the research machines with source available is required to sign a non-disclosure agreement. The agreement is basically a reproduction of the part of the license governing non-disclosure, and a statement that they had read and understood it, and would abide by it. Everybody, including faculty, signs it. One the other hand, on the Pyramid where we run only binaries and no source is available, so the campus department administering it doesn't require any signatures. That may soon change, however, since we want to get source on that machine. If it means getting hundreds of students to sign a non-disclosure agreemen, we will. Our lawyers here are rather touchy about things like that. -- Gene "6 months and counting" Spafford The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332 CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf