[TUHS] History of cal(1)?

[TUHS] History of cal(1)?

[Douglas McIlroy via TUHS]

> [cal(1)] has all the logic to adjust for 16th century
> calendar changes ...  (Try "cal 9 1752")
> My impression is that [it is] overimplemented.

The fact that a 16th century change is illustrated by an 18th century
example suggests that not quite "all the logic" is there. It's good
for Great Britain and its colonies, but not elsewhere. So I'd say it's
underimplemented :)

Doug

[TUHS] Re: History of cal(1)?

[John Levine via TUHS]

It appears that Douglas McIlroy via TUHS <douglas.mcilroy@dartmouth.edu> said:
>> [cal(1)] has all the logic to adjust for 16th century
>> calendar changes ...  (Try "cal 9 1752")
>> My impression is that [it is] overimplemented.
>
>The fact that a 16th century change is illustrated by an 18th century
>example suggests that not quite "all the logic" is there. It's good
>for Great Britain and its colonies, but not elsewhere. So I'd say it's
>underimplemented :)

You'll be relieved to know that ncal has addressed that omission:

$ ncal -p
 AL Albania        1912-11-30      IS Iceland        1700-11-16
 AT Austria        1583-10-05      IT Italy          1582-10-04
 AU Australia      1752-09-02      JP Japan          1918-12-18
 BE Belgium        1582-12-14      LT Lithuania      1918-02-01
 BG Bulgaria       1916-03-31      LU Luxembourg     1582-12-14
 CA Canada         1752-09-02      LV Latvia         1918-02-01
 CH Switzerland    1655-02-28      NL Netherlands    1582-12-14
 CN China          1911-12-18      NO Norway         1700-02-18
 CZ Czech Republic 1584-01-06      PL Poland         1582-10-04
 DE Germany        1700-02-18      PT Portugal       1582-10-04
 DK Denmark        1700-02-18      RO Romania        1919-03-31
 ES Spain          1582-10-04      RU Russia         1918-01-31
 FI Finland        1753-02-17      SI Slovenia       1919-03-04
 FR France         1582-12-09      SE Sweden         1753-02-17
 GB United Kingdom 1752-09-02      TR Turkey         1926-12-18
 GR Greece         1924-03-09     *US United States  1752-09-02
 HU Hungary        1587-10-21      YU Yugoslavia     1919-03-04

R's,
John

PS: my point was not that it's a lot of code, but that is's a distinctive hack so one might
look at earlier calendar programs to see whether they also did it to try and trace the
chain of influence.

[TUHS] Re: History of cal(1)?

[Steffen Nurpmeso via TUHS]

John Levine via TUHS wrote in
 <20250923003454.03671DD56E9A@ary.qy>:
 |It appears that Douglas McIlroy via TUHS <douglas.mcilroy@dartmouth.edu> \
 |said:
 |>> [cal(1)] has all the logic to adjust for 16th century
 |>> calendar changes ...  (Try "cal 9 1752")
 |>> My impression is that [it is] overimplemented.
 |>
 |>The fact that a 16th century change is illustrated by an 18th century
 |>example suggests that not quite "all the logic" is there. It's good
 |>for Great Britain and its colonies, but not elsewhere. So I'd say it's
 |>underimplemented :)
 |
 |You'll be relieved to know that ncal has addressed that omission:
 |
 |$ ncal -p
 | AL Albania        1912-11-30      IS Iceland        1700-11-16
 | AT Austria        1583-10-05      IT Italy          1582-10-04
 | AU Australia      1752-09-02      JP Japan          1918-12-18
 | BE Belgium        1582-12-14      LT Lithuania      1918-02-01
 | BG Bulgaria       1916-03-31      LU Luxembourg     1582-12-14
 | CA Canada         1752-09-02      LV Latvia         1918-02-01
 | CH Switzerland    1655-02-28      NL Netherlands    1582-12-14
 | CN China          1911-12-18      NO Norway         1700-02-18
 | CZ Czech Republic 1584-01-06      PL Poland         1582-10-04
 | DE Germany        1700-02-18      PT Portugal       1582-10-04

(In an earlier thread on this topic Mr. McIlroy threw into
the discussion that for example Germany was very much more
complicated than that.  And i said iirc something like "we
tried to keep it local by then" [actually notoriously so], and
unfortunately talked about Mors Teutonicus even, as "we more
usually than not reached the Holy Land" before reaching the holy
land, which *possibly* is the only one and true way to reach the
holy land .. if you can.  (Pffffhh, what a talk.))

 | DK Denmark        1700-02-18      RO Romania        1919-03-31
 | ES Spain          1582-10-04      RU Russia         1918-01-31
 | FI Finland        1753-02-17      SI Slovenia       1919-03-04
 | FR France         1582-12-09      SE Sweden         1753-02-17
 | GB United Kingdom 1752-09-02      TR Turkey         1926-12-18
 | GR Greece         1924-03-09     *US United States  1752-09-02
 | HU Hungary        1587-10-21      YU Yugoslavia     1919-03-04
 |
 |R's,
 |John
 |
 |PS: my point was not that it's a lot of code, but that is's a distinctive \
 |hack so one might
 |look at earlier calendar programs to see whether they also did it to \
 |try and trace the
 |chain of influence.
 --End of <20250923003454.03671DD56E9A@ary.qy>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Re: History of cal(1)?

[Rob Pike via TUHS]

There are so many calendars in the world. The Muslim calendar. The Jewish
calendar. The Mayan calendar. Countless indigenous calendars too, I am
certain.

Whenever computing butts up against real human culture, things get messy
fast. No point in trying to catalog the mess exhaustively.

-rob


On Tue, Sep 23, 2025 at 11:14 AM Steffen Nurpmeso via TUHS <tuhs@tuhs.org>
wrote:

> John Levine via TUHS wrote in
>  <20250923003454.03671DD56E9A@ary.qy>:
>  |It appears that Douglas McIlroy via TUHS <douglas.mcilroy@dartmouth.edu>
> \
>  |said:
>  |>> [cal(1)] has all the logic to adjust for 16th century
>  |>> calendar changes ...  (Try "cal 9 1752")
>  |>> My impression is that [it is] overimplemented.
>  |>
>  |>The fact that a 16th century change is illustrated by an 18th century
>  |>example suggests that not quite "all the logic" is there. It's good
>  |>for Great Britain and its colonies, but not elsewhere. So I'd say it's
>  |>underimplemented :)
>  |
>  |You'll be relieved to know that ncal has addressed that omission:
>  |
>  |$ ncal -p
>  | AL Albania        1912-11-30      IS Iceland        1700-11-16
>  | AT Austria        1583-10-05      IT Italy          1582-10-04
>  | AU Australia      1752-09-02      JP Japan          1918-12-18
>  | BE Belgium        1582-12-14      LT Lithuania      1918-02-01
>  | BG Bulgaria       1916-03-31      LU Luxembourg     1582-12-14
>  | CA Canada         1752-09-02      LV Latvia         1918-02-01
>  | CH Switzerland    1655-02-28      NL Netherlands    1582-12-14
>  | CN China          1911-12-18      NO Norway         1700-02-18
>  | CZ Czech Republic 1584-01-06      PL Poland         1582-10-04
>  | DE Germany        1700-02-18      PT Portugal       1582-10-04
>
> (In an earlier thread on this topic Mr. McIlroy threw into
> the discussion that for example Germany was very much more
> complicated than that.  And i said iirc something like "we
> tried to keep it local by then" [actually notoriously so], and
> unfortunately talked about Mors Teutonicus even, as "we more
> usually than not reached the Holy Land" before reaching the holy
> land, which *possibly* is the only one and true way to reach the
> holy land .. if you can.  (Pffffhh, what a talk.))
>
>  | DK Denmark        1700-02-18      RO Romania        1919-03-31
>  | ES Spain          1582-10-04      RU Russia         1918-01-31
>  | FI Finland        1753-02-17      SI Slovenia       1919-03-04
>  | FR France         1582-12-09      SE Sweden         1753-02-17
>  | GB United Kingdom 1752-09-02      TR Turkey         1926-12-18
>  | GR Greece         1924-03-09     *US United States  1752-09-02
>  | HU Hungary        1587-10-21      YU Yugoslavia     1919-03-04
>  |
>  |R's,
>  |John
>  |
>  |PS: my point was not that it's a lot of code, but that is's a
> distinctive \
>  |hack so one might
>  |look at earlier calendar programs to see whether they also did it to \
>  |try and trace the
>  |chain of influence.
>  --End of <20250923003454.03671DD56E9A@ary.qy>
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>

[TUHS] Re: History of cal(1)?

[Bakul Shah via TUHS]

Things get quite complicated when you have lunisolar calendars!
An extra lunar month is added every 32 or 33 lunar months to sync
up with the solar cycle[1]. In India they have been in use for
many centuries and even today most religious festivals and events
follow them. Here's a typical calendar page[2]:

https://www.prokerala.com/general/calendar/hinducalendar.php?year=2025&mon=september&sb=1#calendar

As you can see plenty of information is imparted[3]. When I was
a kid, we would always get a day-per-page calendar every year
because of this.


[1] One's birthday as per Indian & Greorian calendars lines up almost
    exactly every 19 years.
[2] Not sure what software they use. The calendar also changes based
    on your location!
[3] Things like sunrise/sunset, the zodiac moon is passing through,
    etc. Details explained here:
      https://www.anaadi.org/post/indian-calendar-part-3-the-panchangam

> On Sep 22, 2025, at 6:50 PM, Rob Pike via TUHS <tuhs@tuhs.org> wrote:
> 
> There are so many calendars in the world. The Muslim calendar. The Jewish
> calendar. The Mayan calendar. Countless indigenous calendars too, I am
> certain.
> 
> Whenever computing butts up against real human culture, things get messy
> fast. No point in trying to catalog the mess exhaustively.
> 
> -rob
> 
> 
> On Tue, Sep 23, 2025 at 11:14 AM Steffen Nurpmeso via TUHS <tuhs@tuhs.org>
> wrote:
> 
>> John Levine via TUHS wrote in
>> <20250923003454.03671DD56E9A@ary.qy>:
>> |It appears that Douglas McIlroy via TUHS <douglas.mcilroy@dartmouth.edu>
>> \
>> |said:
>> |>> [cal(1)] has all the logic to adjust for 16th century
>> |>> calendar changes ...  (Try "cal 9 1752")
>> |>> My impression is that [it is] overimplemented.
>> |>
>> |>The fact that a 16th century change is illustrated by an 18th century
>> |>example suggests that not quite "all the logic" is there. It's good
>> |>for Great Britain and its colonies, but not elsewhere. So I'd say it's
>> |>underimplemented :)
>> |
>> |You'll be relieved to know that ncal has addressed that omission:
>> |
>> |$ ncal -p
>> | AL Albania        1912-11-30      IS Iceland        1700-11-16
>> | AT Austria        1583-10-05      IT Italy          1582-10-04
>> | AU Australia      1752-09-02      JP Japan          1918-12-18
>> | BE Belgium        1582-12-14      LT Lithuania      1918-02-01
>> | BG Bulgaria       1916-03-31      LU Luxembourg     1582-12-14
>> | CA Canada         1752-09-02      LV Latvia         1918-02-01
>> | CH Switzerland    1655-02-28      NL Netherlands    1582-12-14
>> | CN China          1911-12-18      NO Norway         1700-02-18
>> | CZ Czech Republic 1584-01-06      PL Poland         1582-10-04
>> | DE Germany        1700-02-18      PT Portugal       1582-10-04
>> 
>> (In an earlier thread on this topic Mr. McIlroy threw into
>> the discussion that for example Germany was very much more
>> complicated than that.  And i said iirc something like "we
>> tried to keep it local by then" [actually notoriously so], and
>> unfortunately talked about Mors Teutonicus even, as "we more
>> usually than not reached the Holy Land" before reaching the holy
>> land, which *possibly* is the only one and true way to reach the
>> holy land .. if you can.  (Pffffhh, what a talk.))
>> 
>> | DK Denmark        1700-02-18      RO Romania        1919-03-31
>> | ES Spain          1582-10-04      RU Russia         1918-01-31
>> | FI Finland        1753-02-17      SI Slovenia       1919-03-04
>> | FR France         1582-12-09      SE Sweden         1753-02-17
>> | GB United Kingdom 1752-09-02      TR Turkey         1926-12-18
>> | GR Greece         1924-03-09     *US United States  1752-09-02
>> | HU Hungary        1587-10-21      YU Yugoslavia     1919-03-04
>> |
>> |R's,
>> |John
>> |
>> |PS: my point was not that it's a lot of code, but that is's a
>> distinctive \
>> |hack so one might
>> |look at earlier calendar programs to see whether they also did it to \
>> |try and trace the
>> |chain of influence.
>> --End of <20250923003454.03671DD56E9A@ary.qy>
>> 
>> --steffen
>> |
>> |Der Kragenbaer,                The moon bear,
>> |der holt sich munter           he cheerfully and one by one
>> |einen nach dem anderen runter  wa.ks himself off
>> |(By Robert Gernhardt)
>> 

[TUHS] Re: History of cal(1)?

[Noel Chiappa via TUHS]

    > From: Dan Cross

    > Multics calendar does not appear to handle the Sep 1752 switch, however.

Well, I doubt anyone's going to print a September, 1752 calendar, right? :-)

	Noel

[TUHS] Re: History of cal(1)?

[Cameron Míċeál Tyre via TUHS]

Noel,

Ever since a fella sawed through a 6.6kV AC cable next to the factory my dad worked in at the time, apparently using the logic...
if (date = holiday_weekend && nobody_around = TRUE){
      cut_cable();
      }
...it has been my firm belief that there's always at least one person, somewhere, ready to do what most of us would dismiss as crazy or unnecessary.

I can't remember who started off this thread about cal(1) but I'm very grateful as it has sent me down a rabbit hole of great depth, searching for cal source code and also comparing different versions of cal in terms of behavior. Cool stuff.

Best,

Cameron


Sent from Proton Mail Android


-------- Original Message --------
On 22/09/2025 17:07, Noel Chiappa via TUHS <tuhs@tuhs.org> wrote:

>      > From: Dan Cross
>  
>      > Multics calendar does not appear to handle the Sep 1752 switch, however.
>  
>  Well, I doubt anyone's going to print a September, 1752 calendar, right? :-)
>  
>  	Noel
>

[TUHS] Re: History of cal(1)?

[Douglas McIlroy via TUHS]

Multics established connections between BTL and MIT, as did Unix
between BTL and many CS departments. However, I don't remember much
communication with MIT about Unix. Perhaps that is because MIT was not
an early adopter, so by the time Unix arrived there connections ran
every which way, not just to the hub at Murray Hill.

Early adoption was precluded by the MIT legal department's opinion
that AT&T's trade-secret assertion was too onerous. As I understand
it, the main sticking point was that one was not supposed to use
anything one learned from Unix code in any other context. I don't how
other universities' legal departments regarded the trade
secret--perhaps that the cat was so far out of the bag that strict
enforcement was impossible.

I'd love to hear how MIT's Unix ban was broken, and how long it took
for that to happen.

Doug

[TUHS] Re: History of cal(1)?

[Theodore Ts'o via TUHS]

On Thu, Sep 18, 2025 at 11:41:05PM -0400, Douglas McIlroy via TUHS wrote:
> Early adoption was precluded by the MIT legal department's opinion
> that AT&T's trade-secret assertion was too onerous. As I understand
> it, the main sticking point was that one was not supposed to use
> anything one learned from Unix code in any other context. I don't how
> other universities' legal departments regarded the trade
> secret--perhaps that the cat was so far out of the bag that strict
> enforcement was impossible.
> 
> I'd love to hear how MIT's Unix ban was broken, and how long it took
> for that to happen.

The way that I heard the story was that MIT lawyers interpreted the
trade-secret assertion that since it included the magic term "methods
and concepts", if any MIT student was exposed to Unix's "methods and
concepts", they would be subject to the trade secret restrictions.
This was interpreted as "MIT students would be contiminated and might
not be able to be able to work for other employers or do various work
in the future, and We Won't Stand For It."

The way it was broken was that someone managed to get an MIT Alum
working at AT&T as some high-ranking muckety-muck to give MIT a
license where the contract did *not* have the Methods and Concepts
clause.  The problem with that was that AT&T legal *hated* the fact
that MIT had a license without the Methods and Concepts clause, and so
they refused to acknolwedge to other companies (say, such as Digital),
that MIT had a valid Unix source license, and so this prevented MIT
Project Athena from getting an official Ultrix source license.

But thanks to some other MIT alum, MIT Project Athena mysteriously got
an Ultrix sourc tree that had core dumps in it, that was apparently an
taken from some engineering machine, as opposed to an official Digital
source release.

Now, I wasn't there so this is a second or third-hand story; nor have
I seen the purpoted license w/o the Methods and Concepts clause.  But
I have seen the unofficial Ultrix source tree in an MIT AFS volume.

Based on this story, if it is true, even though I have been exposed to
Unix source code from before the BSD distribution on the 'Net, as far
as I know, I was never subject to the Methods and Concepts clause,
because MIT has a Unix license without that clause.

In any case, given that I never signed any NDA when I Started working
as a student systems programmer, the way Trade Secret law works, I
would never have been liability; the legal risk would have been solely
bourne by MIT.  And apparently, MIT at one point wasn't willing to
take that legal risk, or require students to sign NDA's.  I'm guessing
UCB's lawyers had a different understanding of the Methods and
Concepts clause, or perhaps didn't take it seriously?  As far as I
know no staff or students at UCB signed contracts binding them to
adhere to keeping AT&T's trade secrets, right?  If that's true, the
trade secret would have been doomed anyway.

Cheers,

						- Ted

[TUHS] Re: History of cal(1)?

[Rich Salz via TUHS]

More fun Trade Secret stories. I think around the time that Usenix was
funding UUNet, Rick Adams asked an ATT lawyer what would happen if someone
uploaded all the Unix source to Usenet from a payphone. "He gulped" and
admitted the trade secret protection would be gone.  Perhaps Clem was in
the room where that conversation happened.

[TUHS] Re: History of cal(1)?

[Clem Cole via TUHS]

On Fri, Sep 19, 2025 at 12:21 PM Rich Salz via TUHS <tuhs@tuhs.org> wrote:

> More fun Trade Secret stories. I think around the time that Usenix was
> funding UUNet, Rick Adams asked an ATT lawyer what would happen if someone
> uploaded all the Unix source to Usenet from a payphone. "He gulped" and
> admitted the trade secret protection would be gone.  Perhaps Clem was in
> the room where that conversation happened.
>
Nope.

But the difference is that CMU's lawyers made any student who had AT&T code
sign an NDA  (even for the OS course).   They wanted to ensure we
understand the source code we were using for the class had a copyright and
that we would not share that >>source<< with anyone.  But when we signed
that document, the CMU lawyers stated explicitly to us (and also supposedly
had reminded AT&T's lawyers) that under PA law, there were two items:

   1. anything we >>learned<< was ours to keep, and
   2. the AT&T license could not restrict someone from working at Place X
   because once they saw Place Y's IP.

I believe California has the same law. I do know that in Massachusetts,
from being personally involved when Tom Teixeria and I left Masscomp for
Stellar, Masscomp could not stop us (which, at the time, Gus Klein, who had
recently been named President of Masscomp, tried to sue. These two points
held firm — Gus eventually backed off).

BTW: I also know that the trade secret was the crux of the  AT&T vs
BSDi/UCB [not copyright infringement, like many of us thought initially].
 In the end, the court was explicit: Yes, AT&T owned the IP (i.e., methods
and ideas from UNIX were AT&T's IP).  However, once AT&T allowed someone to
see the IP (much less publish papers and books about said IP in the open), the
IP could not be called a trade secret (I still have my "mentally
contaminated" button that a number of us at UCB had made.  And as we know,
BSDi/UCB prevailed.   FWIW: if AT&T had one, then all of the rewrites of
UNIX's IP [starting with Idris to the then burgeoning Linux] would have
fallen up that rule).

So, it sounds like MIT had the sentence struck, while the lawyers at CMU
and UCB took a similar stance that you cannot create a "mind eraser" and
you cannot keep someone from working, just because they worked for you.

[TUHS] Re: History of cal(1)?

[Theodore Ts'o via TUHS]

On Fri, Sep 19, 2025 at 12:53:21PM -0400, Clem Cole wrote:
> But the difference is that CMU's lawyers made any student who had AT&T code
> sign an NDA  (even for the OS course).   They wanted to ensure we
> understand the source code we were using for the class had a copyright and
> that we would not share that >>source<< with anyone.  But when we signed
> that document, the CMU lawyers stated explicitly to us (and also supposedly
> had reminded AT&T's lawyers) that under PA law, there were two items:
> 
>    1. anything we >>learned<< was ours to keep, and
>    2. the AT&T license could not restrict someone from working at Place X
>    because once they saw Place Y's IP.
> 
> I believe California has the same law. I do know that in Massachusetts,
> from being personally involved when Tom Teixeria and I left Masscomp for
> Stellar, Masscomp could not stop us (which, at the time, Gus Klein, who had
> recently been named President of Masscomp, tried to sue. These two points
> held firm — Gus eventually backed off).

I'm not a lawyer, but I suspect IP law wasn't as settled back then.
Remember, this was before courts ruled that Lotus couldn't copyright
their user interface.  And even if the law was "clear", the way the US
court system works is that the party with the larger legal budget can
often intimidate people who might not be able to afford the best
justice money can buy.

This is what I've learned by hanging around lawyers who disagreed
about whether it was "safe" to ship CDDL-licened ZFS code ported to
GPL-licensed Linux kernel.  It's not just about law, but how litigious
the copyright owner might be, and if the defendant is a small company,
such a lawsuit might be seen as "punching down", but if the defendant
was a large company, it might have very different PR angle, and PR is
often at least as important whether the company prevails in a court of
law (if defendant doesn't go out of business first).

Even if you will eventually win, there's a reason why many people will
settle patent lawsuits because even if you are sure that you are in
the right, it might be cheaper to pay the Danegeld than to eventually
prevail after multiple years of litigation.

So I wouldn't be surprised that different legal teams coming from
different universities might have come out in different places
(especially if they thought they could use their Alumni mafia back
channel to eventually side step the whole issue.  :-)

	    	    	      	  	- Ted

[TUHS] Re: History of cal(1)?

[Warner Losh via TUHS]

On Fri, Sep 19, 2025 at 12:21 PM Theodore Ts'o via TUHS <tuhs@tuhs.org>
wrote:

> On Fri, Sep 19, 2025 at 12:53:21PM -0400, Clem Cole wrote:
> > But the difference is that CMU's lawyers made any student who had AT&T
> code
> > sign an NDA  (even for the OS course).   They wanted to ensure we
> > understand the source code we were using for the class had a copyright
> and
> > that we would not share that >>source<< with anyone.  But when we signed
> > that document, the CMU lawyers stated explicitly to us (and also
> supposedly
> > had reminded AT&T's lawyers) that under PA law, there were two items:
> >
> >    1. anything we >>learned<< was ours to keep, and
> >    2. the AT&T license could not restrict someone from working at Place X
> >    because once they saw Place Y's IP.
> >
> > I believe California has the same law. I do know that in Massachusetts,
> > from being personally involved when Tom Teixeria and I left Masscomp for
> > Stellar, Masscomp could not stop us (which, at the time, Gus Klein, who
> had
> > recently been named President of Masscomp, tried to sue. These two points
> > held firm — Gus eventually backed off).
>
> I'm not a lawyer, but I suspect IP law wasn't as settled back then.
> Remember, this was before courts ruled that Lotus couldn't copyright
> their user interface.  And even if the law was "clear", the way the US
> court system works is that the party with the larger legal budget can
> often intimidate people who might not be able to afford the best
> justice money can buy.
>

It's worse than that. The US joined the Berne Convention in 1980, which
threw a lot of monkey wrenches into things. The 1980 Copyright act changed
a lot of things. Prior to that, you could not copyright software *AT*ALL*.
This is why Unix was done via Trade Secret: they couldn't copyright the
software.


> This is what I've learned by hanging around lawyers who disagreed
> about whether it was "safe" to ship CDDL-licened ZFS code ported to
> GPL-licensed Linux kernel.  It's not just about law, but how litigious
> the copyright owner might be, and if the defendant is a small company,
> such a lawsuit might be seen as "punching down", but if the defendant
> was a large company, it might have very different PR angle, and PR is
> often at least as important whether the company prevails in a court of
> law (if defendant doesn't go out of business first).
>

This is true... It's all about risk. How much risk are you willing to take
with an action? There's never 0 risk. And the answer often depends on the
specifics.


> Even if you will eventually win, there's a reason why many people will
> settle patent lawsuits because even if you are sure that you are in
> the right, it might be cheaper to pay the Danegeld than to eventually
> prevail after multiple years of litigation.
>
> So I wouldn't be surprised that different legal teams coming from
> different universities might have come out in different places
> (especially if they thought they could use their Alumni mafia back
> channel to eventually side step the whole issue.  :-)
>

Yea. It's all about risk. How much risk is there? Do we care? How do we
mitigate it? There's times you "play nice" even if you think the other side
has no case because long-game strategies (like the Alumni mafia) are easier
to get things resolved than an instant head-on collision.

Warner

[TUHS] Re: History of cal(1)?

[John Cowan via TUHS]

That's almost why Harvard settled with Trump.

On Fri, Sep 19, 2025, 6:15 PM Warner Losh via TUHS <tuhs@tuhs.org> wrote:

> On Fri, Sep 19, 2025 at 12:21 PM Theodore Ts'o via TUHS <tuhs@tuhs.org>
> wrote:
>
> > On Fri, Sep 19, 2025 at 12:53:21PM -0400, Clem Cole wrote:
> > > But the difference is that CMU's lawyers made any student who had AT&T
> > code
> > > sign an NDA  (even for the OS course).   They wanted to ensure we
> > > understand the source code we were using for the class had a copyright
> > and
> > > that we would not share that >>source<< with anyone.  But when we
> signed
> > > that document, the CMU lawyers stated explicitly to us (and also
> > supposedly
> > > had reminded AT&T's lawyers) that under PA law, there were two items:
> > >
> > >    1. anything we >>learned<< was ours to keep, and
> > >    2. the AT&T license could not restrict someone from working at
> Place X
> > >    because once they saw Place Y's IP.
> > >
> > > I believe California has the same law. I do know that in Massachusetts,
> > > from being personally involved when Tom Teixeria and I left Masscomp
> for
> > > Stellar, Masscomp could not stop us (which, at the time, Gus Klein, who
> > had
> > > recently been named President of Masscomp, tried to sue. These two
> points
> > > held firm — Gus eventually backed off).
> >
> > I'm not a lawyer, but I suspect IP law wasn't as settled back then.
> > Remember, this was before courts ruled that Lotus couldn't copyright
> > their user interface.  And even if the law was "clear", the way the US
> > court system works is that the party with the larger legal budget can
> > often intimidate people who might not be able to afford the best
> > justice money can buy.
> >
>
> It's worse than that. The US joined the Berne Convention in 1980, which
> threw a lot of monkey wrenches into things. The 1980 Copyright act changed
> a lot of things. Prior to that, you could not copyright software *AT*ALL*.
> This is why Unix was done via Trade Secret: they couldn't copyright the
> software.
>
>
> > This is what I've learned by hanging around lawyers who disagreed
> > about whether it was "safe" to ship CDDL-licened ZFS code ported to
> > GPL-licensed Linux kernel.  It's not just about law, but how litigious
> > the copyright owner might be, and if the defendant is a small company,
> > such a lawsuit might be seen as "punching down", but if the defendant
> > was a large company, it might have very different PR angle, and PR is
> > often at least as important whether the company prevails in a court of
> > law (if defendant doesn't go out of business first).
> >
>
> This is true... It's all about risk. How much risk are you willing to take
> with an action? There's never 0 risk. And the answer often depends on the
> specifics.
>
>
> > Even if you will eventually win, there's a reason why many people will
> > settle patent lawsuits because even if you are sure that you are in
> > the right, it might be cheaper to pay the Danegeld than to eventually
> > prevail after multiple years of litigation.
> >
> > So I wouldn't be surprised that different legal teams coming from
> > different universities might have come out in different places
> > (especially if they thought they could use their Alumni mafia back
> > channel to eventually side step the whole issue.  :-)
> >
>
> Yea. It's all about risk. How much risk is there? Do we care? How do we
> mitigate it? There's times you "play nice" even if you think the other side
> has no case because long-game strategies (like the Alumni mafia) are easier
> to get things resolved than an instant head-on collision.
>
> Warner
>

[TUHS] Re: History of cal(1)?

[Ron Natalie via TUHS]

>>  >
>>
>>  It's worse than that. The US joined the Berne Convention in 1980, which
>>  threw a lot of monkey wrenches into things. The 1980 Copyright act changed
>>  a lot of things. Prior to that, you could not copyright software *AT*ALL*.
>>  This is why Unix was done via Trade Secret: they couldn't copyright the
>>  software.
>
This is untrue.   First, the US didn’t join the Berne Convention until 
1989.
Second, software copyright existed in the US well before Berne.    Much 
analogy was made to piano rolls which were decided well back in 1908,
Software was generally held to be the same sort of literary work that 
anything else was including these piano rolls and phonograph records.
There’s tons of pre-Berne case law on this, Notably Apple v. Franklin, 
and Williams Elec v. Artic Intl.   Both affirm that both the source code 
and the compiled code on computers is protectable.

There were a number of reasons why Western Electric used Trade Secret 
rather than copyright.   Some of it was due to the nature of Bell Labs.
Other, is that when your protecting TECHNOLOGIC INFORMATION, trade 
secret allows you to stop that dissemination.   Copyright, only 
prohibits making copies, but not dissemination of the information and 
patents by their very nature require the information to be disclosed.

-Ron

[TUHS] Re: History of cal(1)?

[Theodore Ts'o via TUHS]

On Thu, Sep 25, 2025 at 02:07:54PM +0000, Ron Natalie via TUHS wrote:
> There were a number of reasons why Western Electric used Trade Secret rather
> than copyright.   Some of it was due to the nature of Bell Labs.
> Other, is that when your protecting TECHNOLOGIC INFORMATION, trade secret
> allows you to stop that dissemination.   Copyright, only prohibits making
> copies, but not dissemination of the information and patents by their very
> nature require the information to be disclosed.

Sure, but only if the owner of that information.... doesn't
disseminate it, at least not without very specfic protections.  That
means no trying to patent the setuid bit (as soon as you do that, it's
no longer subject to trade secrets).  It means no publishing a paper
in CACM (as soon as you do that, the information in that paper is no
longer subject to trade secret).  And if you distribute tapes to people
without requiring them to make sure anyone else they might distribute
to must sign an NDA, it's not going to be protected.

MIT didn't want to get students to sign NDA's that might ihhibit their
ability to do future work, which is why MIT refused to sign a license
with the Methods and Concepts clause.  But if you believe that things
don't work that way, then the trade secret wasn't going to prevent the
dissemination of that technologic information.  

Effectively, Trade Secret is a bilateral thing, and is essentially
something that gets established via a contract.  In practice, there is
*very* little difference between Alice and Bob signing a contract
stating that Bob promises not to share the information (e.g., an NDA)
and Alice and Bob signing a contract stating something is a Trade
Secret.  In both cases there is *very* little Alice can do to hammer
Charlie under law if Charlie receives the information if Charlie
didn't sign a NDA or some other contract acknowledging that a
particular bit of information is a trade secret.

I've handled Trade Secrets before in my time.  Some of this was
pre-release information about Itanium.  In that case, the information
was in a orange-covered book, with large letters on the cover saying
that it was Intel Proprietary Information, and I had to sign a piece
of paper stating that I had received a numbered copy of the
information, and I had to promise not to share it and to keep it
locked up if I wasn't using it.

I've had colleagues who worked with pre-release information for the
Sony Playstation, and in that case the information had to be kept in a
locked room, and couldn't be taken out of the room --- and I've
handled U.S. government classified information that had fewer
protections that the Sony information was required to have.

This is not "publish it in CACM and then try to think that you can
stop dissemination about the technical information."  This is why when
the encryption key for DVD copy protection was published on the
internet, athough that was presumably trade secret informtion, there
was zilch that could be done to stop the dissemination of the
encryption key.

						- Ted

[TUHS] Re: History of cal(1)?

[Paul Winalski via TUHS]

On Thu, Sep 25, 2025 at 10:14 AM Ron Natalie via TUHS <tuhs@tuhs.org> wrote:

>
> There were a number of reasons why Western Electric used Trade Secret
> rather than copyright.   Some of it was due to the nature of Bell Labs.
> Other, is that when your protecting TECHNOLOGIC INFORMATION, trade
> secret allows you to stop that dissemination.   Copyright, only
> prohibits making copies, but not dissemination of the information and
> patents by their very nature require the information to be disclosed.
>
> US patent law doesn't specifically mention software.  For a long time the
US PTO, and the courts,  allowed algorithms to be part of a patent
declaration, but only as part of a device.  Algorithms expressed as
software were not in and of themselves patentable.  That stance gradually
changed.

As you point out copyright protects creative expression of an idea or
process.  It does not protect the idea or process itself.  That is what a
patent does, and for a long time software wasn't considered patentable.  So
if you wanted to protect technological information related to software the
alternative you were left with was to make it a trade secret--to legally
require that anyone to which you divulged the secret did not disclose it to
anyone else without your permission.  The advantage of a trade secret is
that the information is not disclosed.  The disadvantage is that if someone
else independently discovers it and obtains a patent for it, the patent
holder may demand that you stop using the idea.

-Paul W.

[TUHS] Re: History of cal(1)?

[Ron Natalie via TUHS]

I don’t disagree, but software copyright is almost as old as software.   
The earliest use was back in 1961, long before UNIX or its predecessors 
existed.
Its nonexistance was not the reason Western Electric didn’t use it.



------ Original Message ------
From "Paul Winalski" <paul.winalski@gmail.com>
To "Ron Natalie" <ron@ronnatalie.com>
Cc "TUHS main list" <tuhs@tuhs.org>
Date 9/25/2025 11:06:09 AM
Subject Re: [TUHS] Re: History of cal(1)?

>On Thu, Sep 25, 2025 at 10:14 AM Ron Natalie via TUHS <tuhs@tuhs.org> 
>wrote:
>>
>>There were a number of reasons why Western Electric used Trade Secret
>>rather than copyright.   Some of it was due to the nature of Bell 
>>Labs.
>>Other, is that when your protecting TECHNOLOGIC INFORMATION, trade
>>secret allows you to stop that dissemination.   Copyright, only
>>prohibits making copies, but not dissemination of the information and
>>patents by their very nature require the information to be disclosed.
>>
>US patent law doesn't specifically mention software.  For a long time 
>the US PTO, and the courts,  allowed algorithms to be part of a patent 
>declaration, but only as part of a device.  Algorithms expressed as 
>software were not in and of themselves patentable.  That stance 
>gradually changed.
>
>As you point out copyright protects creative expression of an idea or 
>process.  It does not protect the idea or process itself.  That is what 
>a patent does, and for a long time software wasn't considered 
>patentable.  So if you wanted to protect technological information 
>related to software the alternative you were left with was to make it a 
>trade secret--to legally require that anyone to which you divulged the 
>secret did not disclose it to anyone else without your permission.  The 
>advantage of a trade secret is that the information is not disclosed.  
>The disadvantage is that if someone else independently discovers it and 
>obtains a patent for it, the patent holder may demand that you stop 
>using the idea.
>
>-Paul W.

[TUHS] Re: History of cal(1)?

[Clem Cole via TUHS]

On Thu, Sep 25, 2025 at 11:09 AM Ron Natalie via TUHS <tuhs@tuhs.org> wrote:

> I don’t disagree, but software copyright is almost as old as software.
> The earliest use was back in 1961, long before UNIX or its predecessors
> existed.
> Its nonexistance was not the reason Western Electric didn’t use it.
>
> But AT&T >>did<< use a copyright on the sources, as I previously sent a
screenful of output from:

cd <Fifth Edition Source Directory>; find . -type f -print | xargs grep -i
Copyright | more

and the >>copyright<< was all we were worried about at the time.  You
can do that with any directory that contains source from AT&T and I bet
you'll find them.  They freely put copyright in everything.  Even early
UNIX itself prints a banner when you log in, stating that Western Electric
holds the copyright on the product you are using.

As I mentioned earlier, CMU did not require us to sign an *NDA*.  What they
asked us to sign was a CMU document that stated we understood this material
was licensed to the University, had an AT&T copyright, and we could not
distribute it to anyone, without permission [at the time, the "permission
gatekeeper was Howard Wakler of the CS Dept, who was responsible for all
the systems, the licenses, et al]

My memory is that >>before<< that, if CS or the Computer Center (IBM shop)
hired you, we had to sign something that said we understood we were
representing the University and we would not put any licenses at risk, and
that was kept in our employee file.   My >>guess< is that what we had to
sign for the OS course was a child of that thinking.  But I never asked him
and have never known if it was Howard's idea to have us sign the
agreement.   My bet is he was part of it.  That was the first OS class that
did not use a "toy OS,"  but rather the 6th Edition of Unix.  My >>guess< is
that the Prof (Anita Jones), who was teaching the OS course, asked Howard
for access to the sources for the students, and Howard likely said - Well,
it's licensed to CMU and has an AT&T copyright on it.  We need to ensure
that they follow the rules for handling licensed IP.

The point is that, as far as I know/can remember, the AT&T UNIX licensees
for whom I worked (CMU, Tektronix, etc) never considered the UNIX IP as a
trade secret.  We did treat it as material with a copyright.  I also have
no recollection of ever hearing anyone at a USENIX talk discuss the "trade
secret" aspect of any AT&T license, nor do I remember it coming up in what
AT&T negotiated with us on the commercial side, specifically regarding a
redistribution license (*i.e*., what would create the System III license).
We did argue about where and how the sources could be stored at these
sites.  IIRC, both the research and commercial use licenses required you to
name the CPU model and serial number. For commercial folks, you paid a CPU
license to have the IP on it.

Simply put, we were worried about infringing on AT&T's copyright and core
"UNIX usage" license.
Clem

[TUHS] Re: History of cal(1)?

[Dave Horsfall via TUHS]

On Thu, 25 Sep 2025, Clem Cole via TUHS wrote:

[...]

> and the >>copyright<< was all we were worried about at the time.  You
> can do that with any directory that contains source from AT&T and I bet
> you'll find them.  They freely put copyright in everything.  Even early
> UNIX itself prints a banner when you log in, stating that Western Electric
> holds the copyright on the product you are using.

Heck; at one time the "true" command was a Shell script with a huge
copyright notice, followed by... nothing...  (The "false" script
actually had "exit 1" at the end.)

-- Dave

[TUHS] Re: History of cal(1)?

[Steffen Nurpmeso via TUHS]

Dave Horsfall via TUHS wrote in
 <alpine.BSF.2.00.2509260628530.88759@aneurin.horsfall.org>:
 |On Thu, 25 Sep 2025, Clem Cole via TUHS wrote:
 |[...]
 |
 |> and the >>copyright<< was all we were worried about at the time.  You
 |> can do that with any directory that contains source from AT&T and I bet
 |> you'll find them.  They freely put copyright in everything.  Even early
 |> UNIX itself prints a banner when you log in, stating that Western \
 |> Electric
 |> holds the copyright on the product you are using.
 |
 |Heck; at one time the "true" command was a Shell script with a huge
 |copyright notice, followed by... nothing...  (The "false" script
 |actually had "exit 1" at the end.)

And today i programmer am still too apprehensive to remove the
complete copyright notice, leaving only the present

 * SPDX-License-Identifier: ISC

though the Linux kernel (but hey: Linux kernel!) goes that way, as
far as i see.  (Likely via a mostly automatized sed(1) run.
It shortens --copyright output to two lines (minimum), in theory.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Re: History of cal(1)?

[Steve Nickolas via TUHS]

On Thu, 25 Sep 2025, Steffen Nurpmeso via TUHS wrote:

> And today i programmer am still too apprehensive to remove the
> complete copyright notice, leaving only the present
>
> * SPDX-License-Identifier: ISC
>
> though the Linux kernel (but hey: Linux kernel!) goes that way, as
> far as i see.  (Likely via a mostly automatized sed(1) run.
> It shortens --copyright output to two lines (minimum), in theory.

I have a policy of always including the full license terms in every source 
file if it's a university-style license (e.g., MIT, BSD, UIUC).  Better 
safe than sorry.  Often I'll *also* include a license.txt with the same 
content.

But I'm weird like that.

-uso.

[TUHS] Re: History of cal(1)?

[jason-tuhs--- via TUHS]

> Heck; at one time the "true" command was a Shell script with a huge 
> copyright notice, followed by... nothing...  (The "false" script 
> actually had "exit 1" at the end.)

From http://web.42.net/true.html

==========================================================================
cat /bin/true

#     Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T;
#       All Rights Reserved

#     THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T;
#     The copyright notice above does not evidence any
#     actual or intended publication of such source code.

#ident  "@(#)true.sh    1.6     93/01/11 SMI"   /* SVr4.0 1.4   */



I'm not sure what I like most.  The fact that they're claiming strict
copyright on a file that is all comments?  The fact that they're up to
version 1.6 of all-comments, after five years of development?  Or the fact
that the GNU version had to be rewritten (due to the above copyright), and
thus actually offers three times as much functionality?

==========================================================================


  -Jason

[TUHS] Re: History of cal(1)?

[segaloco via TUHS]

On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS <tuhs@tuhs.org> wrote:

> > Heck; at one time the "true" command was a Shell script with a huge
> > copyright notice, followed by... nothing... (The "false" script
> > actually had "exit 1" at the end.)
> 
> 
> From http://web.42.net/true.html
> 
> ==========================================================================
> cat /bin/true
> 
> # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T;
> # All Rights Reserved
> 
> # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T;
> # The copyright notice above does not evidence any
> # actual or intended publication of such source code.
> 
> #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
> 
> 
> 
> I'm not sure what I like most. The fact that they're claiming strict
> copyright on a file that is all comments? The fact that they're up to
> version 1.6 of all-comments, after five years of development? Or the fact
> that the GNU version had to be rewritten (due to the above copyright), and
> thus actually offers three times as much functionality?
> 
> ==========================================================================
> 
> 
> -Jason

So assuming the whole text of the program after the copyright statement itself as well as the source control statements is truly AT&T property...does that mean AT&T lays copyright to the empty file?  I jest but it is an interesting suggestion.

It also brought to mind the question of whether a UNIX superblock for instance could be placed under copyright?  The files on the disk, sure, but since you can't easily put elaborate license comments at the top of the filesystem itself, is filesystem metadata inherently "un-copyright-able"?  Mostly interested in UNIX filesystems on this subject but if other systems or general wisdom prevail in the discussion then that bit can fork to COFF.

- Matt G.

[TUHS] Re: History of cal(1)?

[John Levine via TUHS]

It appears that segaloco via TUHS <segaloco@protonmail.com> said:
>It also brought to mind the question of whether a UNIX superblock for instance could be placed under copyright?  The files on the disk, sure, but since you can't easily put
>elaborate license comments at the top of the filesystem itself, is filesystem metadata inherently "un-copyright-able"?  Mostly interested in UNIX filesystems on this subject
>but if other systems or general wisdom prevail in the discussion then that bit can fork to COFF.

Copyright notices in the U.S. haven't been needed since we joined Berne in 1989.

On the other hand, I think there is a strong argument that the metadata is functional so it's
not eligible for copyright, or even if it is, Oracle vs. Google said (rather oversimplifying)
copying is OK if it's essential to making something interoperate.

R's,
John

PS: We're pretty deep in the weeds here.

[TUHS] Re: History of cal(1)?

[Warner Losh via TUHS]

On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS <
> tuhs@tuhs.org> wrote:
>
> > > Heck; at one time the "true" command was a Shell script with a huge
> > > copyright notice, followed by... nothing... (The "false" script
> > > actually had "exit 1" at the end.)
> >
> >
> > From http://web.42.net/true.html
> >
> >
> ==========================================================================
> > cat /bin/true
> >
> > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T;
> > # All Rights Reserved
> >
> > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T;
> > # The copyright notice above does not evidence any
> > # actual or intended publication of such source code.
> >
> > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
> >
> >
> >
> > I'm not sure what I like most. The fact that they're claiming strict
> > copyright on a file that is all comments? The fact that they're up to
> > version 1.6 of all-comments, after five years of development? Or the fact
> > that the GNU version had to be rewritten (due to the above copyright),
> and
> > thus actually offers three times as much functionality?
> >
> >
> ==========================================================================
> >
> >
> > -Jason
>
> So assuming the whole text of the program after the copyright statement
> itself as well as the source control statements is truly AT&T
> property...does that mean AT&T lays copyright to the empty file?  I jest
> but it is an interesting suggestion.
>

I think this credits too much intentionality... but you can't copyright
nothing, despite the claims here. There's no creative content.

Also, we all know this was done by the sed-o-matic on every file without
thinking. So from that perspective, it's not additive to nothing...

It also brought to mind the question of whether a UNIX superblock for
> instance could be placed under copyright?  The files on the disk, sure, but
> since you can't easily put elaborate license comments at the top of the
> filesystem itself, is filesystem metadata inherently "un-copyright-able"?
> Mostly interested in UNIX filesystems on this subject but if other systems
> or general wisdom prevail in the discussion then that bit can fork to COFF.
>

Not applicable. The instance of the data and its structure cannot be
copyright. It's an idea. The header file that describes it can be
copyright. But I can write an equivalent one too (whether or not I saw the
original). Not all books about white whales are owned by the estate of
Herman Melville...

So fs.h can be copyrighted to a degree. All the comments are copyrightable.
The data structures enjoy somewhat less copyright protection. The structure
names and element names may have some copyright, or may not if the names
are important for interop. Some may be common data structures that are too
common. You wouldn't know for sure until the end of any litigation.

It's the uncertainty that drives people to the maximalist position. I know
I won't get in trouble if I never look...

Warner

- Matt G.
>

[TUHS] Re: History of cal(1)?

[segaloco via TUHS]

Sent with Proton Mail secure email.

On Thursday, September 25th, 2025 at 20:18, Warner Losh via TUHS <tuhs@tuhs.org> wrote:

> On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS tuhs@tuhs.org wrote:
> 
> > On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS <
> > tuhs@tuhs.org> wrote:
> > 
> > > > Heck; at one time the "true" command was a Shell script with a huge
> > > > copyright notice, followed by... nothing... (The "false" script
> > > > actually had "exit 1" at the end.)
> > > 
> > > From http://web.42.net/true.html
> > 
> > ==========================================================================
> > 
> > > cat /bin/true
> > > 
> > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T;
> > > # All Rights Reserved
> > > 
> > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T;
> > > # The copyright notice above does not evidence any
> > > # actual or intended publication of such source code.
> > > 
> > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
> > > 
> > > I'm not sure what I like most. The fact that they're claiming strict
> > > copyright on a file that is all comments? The fact that they're up to
> > > version 1.6 of all-comments, after five years of development? Or the fact
> > > that the GNU version had to be rewritten (due to the above copyright),
> > > and
> > > thus actually offers three times as much functionality?
> > 
> > ==========================================================================
> > 
> > > -Jason
> > 
> > So assuming the whole text of the program after the copyright statement
> > itself as well as the source control statements is truly AT&T
> > property...does that mean AT&T lays copyright to the empty file? I jest
> > but it is an interesting suggestion.
> 
> 
> I think this credits too much intentionality... but you can't copyright
> nothing, despite the claims here. There's no creative content.
> 
> Also, we all know this was done by the sed-o-matic on every file without
> thinking. So from that perspective, it's not additive to nothing...
> 
> It also brought to mind the question of whether a UNIX superblock for
> 
> > instance could be placed under copyright? The files on the disk, sure, but
> > since you can't easily put elaborate license comments at the top of the
> > filesystem itself, is filesystem metadata inherently "un-copyright-able"?
> > Mostly interested in UNIX filesystems on this subject but if other systems
> > or general wisdom prevail in the discussion then that bit can fork to COFF.
> 
> 
> Not applicable. The instance of the data and its structure cannot be
> copyright. It's an idea. The header file that describes it can be
> copyright. But I can write an equivalent one too (whether or not I saw the
> original). Not all books about white whales are owned by the estate of
> Herman Melville...
> 
> So fs.h can be copyrighted to a degree. All the comments are copyrightable.
> The data structures enjoy somewhat less copyright protection. The structure
> names and element names may have some copyright, or may not if the names
> are important for interop. Some may be common data structures that are too
> common. You wouldn't know for sure until the end of any litigation.
> 
> It's the uncertainty that drives people to the maximalist position. I know
> I won't get in trouble if I never look...
> 
> Warner
> 
> - Matt G.

I meant more along the lines of a specific disk, a physical instance.  Barring some ability to pursue damages on theft or something, imagine for instance using copyright law to prohibit distribution of some snapshot of a filesystem header, on the grounds that even the directory information has been claimed as under copyright by the owner of that physical piece of media.  Indeed this is in the weeds but just felt like an amusing parallel to the idea of copyrighting an empty file.  It's a construct more than it is original, intentional content.  To oversimplify it, could the output from ls(1) in a directory be copyrighted by the person who happened to type "ls"?

- Matt G.

[TUHS] Re: History of cal(1)?

[Dan Cross via TUHS]

[Honoring wkt's recent request for this discussion to migrate to COFF,
sending TUHS to Bcc]

While this discussion moves to COFF, there is a Unix tie-in
specifically with respect to the empty-file `true`: Gerard Holzmann
wrote a nice article about this several years ago in the "Reliable
Code" column of IEEE Software, titled, "Code Inflation". It's not
long, and it's a very fun read. Themes he explores may resonate well
with the average TUHS reader:
https://spinroot.com/gerard/pdf/Code_Inflation.pdf

As an aside, the implementation of `true` as an empty file relies on a
quirk of `sh` to work: `sh` would try to invoke a program via `exec`,
and if that failed, would then try to interpret it as a shell script.
Since a zero-byte file is not a valid binary executable for invocation
via `exec`, this would fail; the shell would then try to interpret it,
do nothing (as there was nothing to do), and exit with its default
value (0), indicating success.  But a side-effect of this is that one
cannot directly `exec` true and expect success; the result is an
error.  "Why would anyone want to do that, anyway?" Good question; I
suspect they wouldn't in the normal case. But I can imagine someone
linking `true` to something they expect to succeed to, or specifying
it as an argument to something in lieu of another command they didn't
want to bother with (perhaps an editor or something).

Perhaps `true` should be, `#!/bin/sh` and nothing else, but `exec`
support for invoking interpreters via the `#!` syntax came in 4.1BSD,
well after zero-byte `/bin/true`.

A random thought: some versions of UFS have support for something they
call "fast symlinks".  Symbolic links, of course, are just files that
contain a string naming some other file, and if a pathname has a
component naming a symlink when walked by `namei`, that string is
substituted for the name of the symlink.  But often these names are
very short, and recall that the `inode` contains some space for disk
block addresses (60 bytes in UFS on 4.1C, but this got bigger in later
versions).  The idea with fast symlinks is that, if the target file
name of a symlink is short enough, the system can just store it in the
space that would normally be used for block addresses; there's no need
to allocate a separate fragment from a disk block, let alone bear the
cost of allocating a buffer and fetching a block from disk, if a short
name can be written directly into the inode.

I don't think anyone ever gave serious thought to generalizing this
facility for very small files, but in principle, one could store their
contents in a similar manner (think of all those random little files
that just have a pid in them or something).  In that case, one wonders
what the smallest executable binary implementing `_exit(0)` is.  Some
folks have played around with hacks and gotten very small files
indeed: less than 120 bytes for ELF files, for example, and with
a.out, it would have been even smaller. So, it raises the question:
could one have written a hyper-size optimized version of `true` that
generated a very, very small executable binary that was embedded
directly into its inode in the form of one of these hypothetical short
files, but still executable? I suspect the answer is "yes".

For the record, I don't think this would have any _practical_ utility,
and putting effort into such a thing for real work would be about as
useful as adding a `--false` flag to `true`. But it would be a neat
hack.

On Thu, Sep 25, 2025 at 11:32 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> On Thursday, September 25th, 2025 at 20:18, Warner Losh via TUHS <tuhs@tuhs.org> wrote:
> > On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS tuhs@tuhs.org wrote:
> >
> > > On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS <
> > > tuhs@tuhs.org> wrote:
> > >
> > > > > Heck; at one time the "true" command was a Shell script with a huge
> > > > > copyright notice, followed by... nothing... (The "false" script
> > > > > actually had "exit 1" at the end.)
> > > >
> > > > From http://web.42.net/true.html
> > >
> > > ==========================================================================
> > >
> > > > cat /bin/true
> > > >
> > > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T;
> > > > # All Rights Reserved
> > > >
> > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T;
> > > > # The copyright notice above does not evidence any
> > > > # actual or intended publication of such source code.
> > > >
> > > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
> > > >
> > > > I'm not sure what I like most. The fact that they're claiming strict
> > > > copyright on a file that is all comments? The fact that they're up to
> > > > version 1.6 of all-comments, after five years of development? Or the fact
> > > > that the GNU version had to be rewritten (due to the above copyright),
> > > > and
> > > > thus actually offers three times as much functionality?
> > >
> > > ==========================================================================
> > >
> > > > -Jason
> > >
> > > So assuming the whole text of the program after the copyright statement
> > > itself as well as the source control statements is truly AT&T
> > > property...does that mean AT&T lays copyright to the empty file? I jest
> > > but it is an interesting suggestion.
> >
> > I think this credits too much intentionality... but you can't copyright
> > nothing, despite the claims here. There's no creative content.
> >
> > Also, we all know this was done by the sed-o-matic on every file without
> > thinking. So from that perspective, it's not additive to nothing...

I suspect the answer to the original question is "no", as it's really
copyrighting nothing, and ... what would that mean?  Can I claim
copyright over the empty set in mathematics?  Surely there must be a
thing in order to claim copyright over that thing; copyrighting the
absence of a thing makes no sense, and we're back to this notion that
you can't copyright an idea.

This feels like one of those weird "physical reality meets the law"
things, like trying to pass a law banning meteor showers or something
goofy like that.

> I meant more along the lines of a specific disk, a physical instance.  Barring some ability to pursue damages on theft or something, imagine for instance using copyright law to prohibit distribution of some snapshot of a filesystem header, on the grounds that even the directory information has been claimed as under copyright by the owner of that physical piece of media.  Indeed this is in the weeds but just felt like an amusing parallel to the idea of copyrighting an empty file.  It's a construct more than it is original, intentional content.  To oversimplify it, could the output from ls(1) in a directory be copyrighted by the person who happened to type "ls"?

Huh. I don't know about a superblock, but it seems unlikely: a
superblock changes all the time during the course of normal operation.
To what would the copyright apply, other than the SB's state at a
specific instance in time? How is that different than, say, trying to
copyright the position of a flywheel in some mechanical engine at a
specific moment in time?

But it is an interesting question.  IIRC Oracle's licensing terms for
its database product are sort of weird in this regard: they license
for a physical processor, and this has given folks all sorts of
headaches when considering virtualized environments.  A question that
has been raised is whether it's a violation of the licensing terms to
migrate the VM running an instance of Oracle to a separate physical
machine, or even snapshot the VM's (memory) state and write it to a
separate machine, then copy it back and resume it (even if the
snapshot doesn't run).

Questions like that make me glad I'm not a lawyer.

        - Dan C.

[TUHS] Re: History of cal(1)?

[Ron Natalie via TUHS]

You can claim copyright for the C code that defines the superblock 
(i.e., the header), but the layout of the superblock itself is not 
something that can be protected by copyright.



------ Original Message ------
From "segaloco via TUHS" <tuhs@tuhs.org>
To "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 9/25/2025 10:08:38 PM
Subject [TUHS] Re: History of cal(1)?

>On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS <tuhs@tuhs.org> wrote:
>
>>  > Heck; at one time the "true" command was a Shell script with a huge
>>  > copyright notice, followed by... nothing... (The "false" script
>>  > actually had "exit 1" at the end.)
>>
>>
>>  From http://web.42.net/true.html
>>
>>  ==========================================================================
>>  cat /bin/true
>>
>>  # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T;
>>  # All Rights Reserved
>>
>>  # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T;
>>  # The copyright notice above does not evidence any
>>  # actual or intended publication of such source code.
>>
>>  #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
>>
>>
>>
>>  I'm not sure what I like most. The fact that they're claiming strict
>>  copyright on a file that is all comments? The fact that they're up to
>>  version 1.6 of all-comments, after five years of development? Or the fact
>>  that the GNU version had to be rewritten (due to the above copyright), and
>>  thus actually offers three times as much functionality?
>>
>>  ==========================================================================
>>
>>
>>  -Jason
>
>So assuming the whole text of the program after the copyright statement itself as well as the source control statements is truly AT&T property...does that mean AT&T lays copyright to the empty file?  I jest but it is an interesting suggestion.
>
>It also brought to mind the question of whether a UNIX superblock for instance could be placed under copyright?  The files on the disk, sure, but since you can't easily put elaborate license comments at the top of the filesystem itself, is filesystem metadata inherently "un-copyright-able"?  Mostly interested in UNIX filesystems on this subject but if other systems or general wisdom prevail in the discussion then that bit can fork to COFF.
>
>- Matt G.

[TUHS] History of cal(1)?

[Dan Cross via TUHS]

Over on the Multicians list, Jeffrey Johnson asked a question about
the Multics `calendar` program, which was written by Tom van Vleck in
Dec, 1973. Despite what some man pages say, the analogous Unix `cal`
program appears to have arrived in the 5th Edition (mid 1974).
Jeffrey's question was whether `cal` was inspired by `calendar`?

My suspicion is that it was not, and this is a case of parallel
invention: after all, a program that prints out a calendar is
obviously useful.  I also suspect that program, or something
substantially similar, had existed for quite a while before someone
tossed it into /usr/source/s1 in time for 5th Edition.  Does anyone
recall who wrote it, and when?

But this also rekindles my curiosity about something I've always
wondered: what _was_ the level of communication between the folks at
Bell Labs and the Multics people after 1969?  By all accounts,
individuals remained friendly and collegial with one another, but it
seems like communication (let alone collaboration) between the two
"camps" was minimal.  Is that accurate?

        - Dan C.

[TUHS] Re: History of cal(1)?

[Cameron Míċeál Tyre via TUHS]

Hi Dan,

This is not a full answer to your question but cal appeared in Research UNIX 1st Edition, Nov 3, 1971.

I'd be interested to compare the source code, in terms of how it was implemented, between the original and the version I have on this phone which is part of util-linux 2.40.2.

Best regards,

Cameron Tyre

[TUHS] Re: History of cal(1)?

[Dan Cross via TUHS]

On Thu, Sep 18, 2025 at 1:36 PM Cameron Míċeál Tyre via TUHS
<tuhs@tuhs.org> wrote:
> Hi Dan,
>
> This is not a full answer to your question but cal appeared in Research UNIX 1st Edition, Nov 3, 1971.

Ah, good catch!  It was in /usr/ken and in section 6 of the manual
(games), not section 1.

> I'd be interested to compare the source code, in terms of how it was implemented, between the original and the version I have on this phone which is part of util-linux 2.40.2.

Well, for starters, I'd guess it was in assembly language.

        - Dan C.

[TUHS] Re: History of cal(1)?

[Clem Cole via TUHS]

On Thu, Sep 18, 2025 at 12:54 PM Dan Cross via TUHS <tuhs@tuhs.org> wrote:

> ...
>
> But this also rekindles my curiosity about something I've always
> wondered: what _was_ the level of communication between the folks at
> Bell Labs and the Multics people after 1969?  By all accounts,
> individuals remained friendly and collegial with one another, but it
> seems like communication (let alone collaboration) between the two
> "camps" was minimal.  Is that accurate?
>
Doug and Ken are the best to answer for the MH folk.

But I'll take a stab at the communications within the CS Research Community
during the 70s, which I lived in.

As we all know, Unix spread quickly outside of MH to researchers, and a
great deal of development took place "on the outside."  Some of those ideas
came back to the Research versions, but not all.   But I think there was a
good bit of cross-pollination within the community — even before Usenet or
the Internet itself.   Sometimes we would swap magnetic tapes directly, and
often we would bring tapes to a conference with our work and come home
with work from others.  We knew each other and talked.

Taking MetCalfe's law into account, because there so many Unix
installations (and we were all talking to each other), that style of
sharing could not happen with Multics,  I will posit that by 1975 most, if
not nearly all, researchers in the systems world were at least familiar
with Elliott Organick's 1972 book — "*The Multics System: An Examination of
its Structure*," and many of us had read it and trying to learn lessons
from it.  It was a text that was referred to in my undergrad OS course, and
by the time I was a grad student working in systems, it was pretty much
assumed that everyone in the room had read it.

I certainly thought Multics had some cool ideas. However, I barely touched
a Multics system in those days via my limited remote access (MIT's system).
And I never physically saw a Multics-capable processor until many years
later. I admit that from reading Organski's book, I had some wild images of
computer operators mounting mag tapes so a program could continue execution
after a segment defined as not being directly addressable.  So while I was
familiar with Multics,  I certainly "knew" a lot more about UNIX.  I had
it, and I was hacking its kernel.   I personally did little of what we call
programming on Multics, and at the same time, I was being paid to program
in Unix (and some TOPS-10/TOPS-20 shop).

I don't think I'm really unique here.   If the data from website
Multicians.org is correct, there were just too few Multics installations to be
found (11 in 1975), and only two were at universities (MIT and the
University of Louisiana). The other nine were at commercial sites.  Note
that in 1975, we know there were at least 5 times the number of Unix
installations.  Most of these sites were ones that had had some level of CS
Research.  By 1979, the numbers were 25 for Multics and over 600 for Unix.

By 1979, Multics OS was stable, and the hardware to run it (the "3rd
generation" H6180 had been on the market since 1973) had certainly matured
from the original GE-645. So why did Multics not play a more significant
role? Once again, core economics of the time played a huge part. If you use
Google AI, it will tell you that a Honeywell H6180 computer system running
Multics, like MIT was running in 1979, had a list price of about $7 million
when it was introduced. This price included a complete system with multiple
components, not just the central computer unit.  Now think about a PDP
11/34, with full 256K bytes of memory, a couple of RK05 and probably an
RP04 equivalent as its disk, 9-track tape, Printonix printer, and 16 serial
ports using after-market DH11 — a pretty standard V7 installation, which
costs approximately $100-150K.  Even if you ran it on a Vax, it was not
more than approximately 3 times that number.  But this is a massive
difference from the $7M for a Multic system.

It's a simple Christenson disruption —  the "lesser" system wins over the
earlier, more "mature", and full-featured, "better" one.  As a result,
cross-pollination opportunities were not available.   Unix/V7 and its
derivatives got the attention of units because the economics favored it.
Just like Linux receives today.

Clem

[TUHS] Re: History of cal(1)?

[Dan Cross via TUHS]

On Thu, Sep 18, 2025 at 3:52 PM Clem Cole <clemc@ccc.com> wrote:
> [snip]
> But I'll take a stab at the communications within the CS Research Community during the 70s, which I lived in.

Thanks, Clem: this is just the sort of thing I am interested in.

I realize this is veering off toward COFF territory, but another
couple of follow-up questions; inline.

> As we all know, Unix spread quickly outside of MH to researchers, and a great deal of development took place "on the outside."  Some of those ideas came back to the Research versions, but not all.   But I think there was a good bit of cross-pollination within the community — even before Usenet or the Internet itself.   Sometimes we would swap magnetic tapes directly, and often we would bring tapes to a conference with our work and come home with work from others.  We knew each other and talked.

So I sort of wonder if the Multics folks also showed up to some of
those conferences: SOSP, for example. I imagine people like Fano and
Corby attended. And the Unix community coalesced quickly and became
quite strong (as we all know), I wonder about interaction with other
communities.

To be a tad pithy about it, did folks get together for coffee during
the hallway track? Grab dinner or a drink in the evening? That kind of
thing.

> Taking MetCalfe's law into account, because there so many Unix installations (and we were all talking to each other), that style of sharing could not happen with Multics,  I will posit that by 1975 most, if not nearly all, researchers in the systems world were at least familiar with Elliott Organick's 1972 book — "The Multics System: An Examination of its Structure," and many of us had read it and trying to learn lessons from it.  It was a text that was referred to in my undergrad OS course, and by the time I was a grad student working in systems, it was pretty much assumed that everyone in the room had read it.
>
> I certainly thought Multics had some cool ideas. However, I barely touched a Multics system in those days via my limited remote access (MIT's system). And I never physically saw a Multics-capable processor until many years later. I admit that from reading Organski's book, I had some wild images of computer operators mounting mag tapes so a program could continue execution after a segment defined as not being directly addressable.  So while I was familiar with Multics,  I certainly "knew" a lot more about UNIX.  I had it, and I was hacking its kernel.   I personally did little of what we call programming on Multics, and at the same time, I was being paid to program in Unix (and some TOPS-10/TOPS-20 shop).
>
> I don't think I'm really unique here.   If the data from website Multicians.org is correct, there were just too few Multics installations to be found (11 in 1975), and only two were at universities (MIT and the University of Louisiana). The other nine were at commercial sites.  Note that in 1975, we know there were at least 5 times the number of Unix installations.  Most of these sites were ones that had had some level of CS Research.  By 1979, the numbers were 25 for Multics and over 600 for Unix.
>
> By 1979, Multics OS was stable, and the hardware to run it (the "3rd generation" H6180 had been on the market since 1973) had certainly matured from the original GE-645. So why did Multics not play a more significant role? Once again, core economics of the time played a huge part. If you use Google AI, it will tell you that a Honeywell H6180 computer system running Multics, like MIT was running in 1979, had a list price of about $7 million when it was introduced. This price included a complete system with multiple components, not just the central computer unit.  Now think about a PDP 11/34, with full 256K bytes of memory, a couple of RK05 and probably an RP04 equivalent as its disk, 9-track tape, Printonix printer, and 16 serial ports using after-market DH11 — a pretty standard V7 installation, which costs approximately $100-150K.  Even if you ran it on a Vax, it was not more than approximately 3 times that number.  But this is a massive difference from the $7M for a Multic system.
>
> It's a simple Christenson disruption —  the "lesser" system wins over the earlier, more "mature", and full-featured, "better" one.  As a result, cross-pollination opportunities were not available.   Unix/V7 and its derivatives got the attention of units because the economics favored it.  Just like Linux receives today.

These are really great points. It sure seems like Multics has had a
huge influence, but indirectly, as it was difficult to come by for
actual use.

Thanks again, Clem.

        - Dan C.

[TUHS] Re: History of cal(1)?

[John Levine via TUHS]

It appears that Dan Cross via TUHS <crossd@gmail.com> said:
>My suspicion is that it was not, and this is a case of parallel
>invention: after all, a program that prints out a calendar is
>obviously useful. ...

It is, but a program that has all the logic to adjust for 16th century
calendar changes, not so much.  (Try "cal 9 1752")

My impression is that the Unix cal program was always this overimplemented
so perhaps we can see whether other earlier programs did that too.

R's,
John

[TUHS] Re: History of cal(1)?

[Dan Cross via TUHS]

On Sat, Sep 20, 2025 at 4:35 PM John Levine <johnl@taugh.com> wrote:
> It appears that Dan Cross via TUHS <crossd@gmail.com> said:
> >My suspicion is that it was not, and this is a case of parallel
> >invention: after all, a program that prints out a calendar is
> >obviously useful. ...
>
> It is, but a program that has all the logic to adjust for 16th century
> calendar changes, not so much.  (Try "cal 9 1752")

The amount of logic required to handle that in the 5th Ed version of
`cal` is surprisingly small, consisting of only three places and
perhaps a total of 8 or 9 lines of code, depending on how one wants to
count.

> My impression is that the Unix cal program was always this overimplemented
> so perhaps we can see whether other earlier programs did that too.

I edited a copy to get it to compile with a recent compiler. The
changes were mainly to modernize the C dialect `=+` vs `+=` and that
kind of thing; I added prototypes in a handful of places, and used ISO
function definitions and a couple of `#include`'s. The result is 214
lines of code, including whitespace.  Forgive me, but I'd hardly call
that "over-implemented."

THVV's Multics calendar program is actually meant to produce printable
calendars to hang on a wall, with enough space that one could write
birthdays and so forth onto them, as one might on a hanging calendar
bought in a store. That program is over a thousand lines of code PL/1
code (including significant comments and whitespace):
https://github.com/dancrossnyc/multics/blob/main/library_dir_dir/system_library_standard/source/bound_printing_cmds_.s.archive/calendar.pl1

Multics calendar does not appear to handle the Sep 1752 switch, however.

        - Dan C.

[TUHS] Re: History of cal(1)?

[Jeff Johnson via TUHS]

You can also look at the code with (what should be) better indentation and proper syntax highlighting at https://dps8m.gitlab.io/sb/MR12.8/library_dir_dir/system_library_standard/source/bound_printing_cmds_.s.archive/calendar.pl1.html

THVV’s also allows adding custom text and holidays before printing and it also includes code for calculating the date of Easter.

It’s a quite the featureful program for when it was introduced.

--
Jeffrey H. Johnson
trnsz@pobox.com