Ugh, I just noticed a flaw in my logic. I was assuming "distribute" means to publically distribute or widely disseminate (e.g. via anon. ftp server, anon. CVS, or the like) to all comers (which is pretty easy to notice), whereas the legal/copyright definition means "give at least 1 copy away to any other legal entity". Thus there could exist a pseudo-secret distro, given only to one's friends or sold to select customers, that the author never finds out about, simply through its obscurity (although the author could ask the distributor if their code is being distributed, and at least DFSG #5 seems to prevent hiding or lying about it); maybe that is what the patch kickback clause is meant to prevent. That seems like a very unlikely case IMHO, and this type of behavior still seems to break the DFSG at least in spirit (Social Contract #2.) if not in the letter. But it at least explains why they thought of it.
-Eric -----Original Message----- From: Eric Sherrill [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2000 4:28 PM To: Elie Rosenblum; Stephen C. North; [EMAIL PROTECTED] Cc: debian-legal@lists.debian.org Subject: RE: AT&T source code agreement Stephen: In my informal opinion, a license closely following the DFSG obviates the need for any "reciprocality" or "notice" clauses respecting code modification, such as ATT License Sec. 4.2. Here's my reasoning. If hackers distribute patched versions of a DFSG-compliant code base, then they must distribute source as well (i.e. no binary-only distros are allowed); therefore, the author can find out what's changed as easily as anybody else. In fact, the author can even require that hackers distribute original source + patches only, to make the changes even more obvious (but this is not encouraged); see DFSG #4. Also, hackers can't restrict the author (here ATT), or anybody else for that matter, from incorporating a released hack/patch into their distro if they like it ; see DFSG #1,3,5,6. Thus Sec. 4.2 is superfluous at best: the author can just hit Freshmeat/anon. CVS/et al. like everybody else & read the source/diffs/patches; and overly restrictive at worst: it makes the author a special case, contra #5, while unduly burdening hackers with notifying the author about every little change. If they are trying to prevent forking, I think RMS and ESR have more than covered that area with their arguments. So why not just strike the clause? (Feel free to %s/hackers/coders/g in the above if it makes the suits happier ;-). -Eric P.S. Needless to say, standard disclaimers apply, even though I AM a lawyer - I'm just not being paid by TI or anybody else to be one at the moment, thus the "inactive status" on my TX bar license. But I do read a lot of debian-legal ;-) (If you want my formal opinion as an attorney, let me know and I'll come out of retirement and re-activate my Texas bar card. Make me an offer I can't refuse....) -- Eric R. Sherrill, WF Software Systems Engineer Texas Instruments HFAB1 Automation Systems Stafford, TX 77477-3006 281-274-4133 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
