[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: AT&T source code agreement

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.


-----Original Message-----
From: Eric Sherrill [mailto:sherrill@hfab1.sc.ti.com]
Sent: Wednesday, March 22, 2000 4:28 PM
To: Elie Rosenblum; Stephen C. North; henning@makholm.net
Cc: debian-legal@lists.debian.org
Subject: RE: AT&T source code agreement


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


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

To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact

Reply to: