A backyard weather website is a stack of other people’s work: a logger, station software, a PHP template, a graphing library, a forecast parse, radar imagery, and sometimes a photo from a visitor bureau. The temperature may be yours. The page is not. A credits page is how an operator says that without turning the site into a legal fiction that the whole stack was original.
The historical TNET Weather page at /tws-credits.php was that citation list for the TWS-prefixed template era. It sat apart from /aboutus.php, which was identity and location. This article is about credits as scientific and legal practice: what to name, how to keep the names durable, and why a credits URL is not an About page. It does not reprint the recovered name-by-name layout, and it does not claim modern TNET authored the historical stack.
Historical context
Weather Display sites borrowed in public. Brian Hamilton’s station software produced the files. Community templates associated with Tom Chaplin’s CarterLake work and Ken True’s Saratoga Weather scripts turned those files into pages. Julian Best’s WDLive and MesoMap viewers were common “live” embeds. JpGraph and similar libraries drew PNG charts. NWS and NOAA products were scraped or linked. Operators then forked CSS, added a local generator, and put a tws- prefix on the files so upgrades would not overwrite the forks.
Somebody still had to say who did what. Early sites buried that in a footer, an About page, or a “tools used” note. The recovered TWS credits page existed because those mentions had spread until they needed a single canonical list. A site-news entry from the same era recorded that credits were pulled out of About on purpose. That split is the right one: About is who operates the station; Credits is who made the tools and supplied the data.
TNET Weather restores /tws-credits.php as an article about that split. Restoration of the hostname is not a transfer of copyright in third-party templates, and it is not an endorsement by any vendor named in historical captures.
What a PWS credits page is for
Credits on a weather site are citations, not thank-you ads. They serve three readers.
The later scientist. A temperature series that passed through Weather Display 10.x, a local parser, and a PNG library is a processed product. Naming the software versions is how a stranger reconstructs the processing. WMO observing practice treats instrument identity as part of the measurement; software identity is the digital equivalent.
The later operator. Template authors learned from each other in forums. A credits page that names the template family (CarterLake, Saratoga, a local TWS fork) tells the next webmaster which documentation to read and which files not to rehost.
The rights holder. Station software, Flash viewers, graphing libraries, and photographs have licenses. A credits page does not create a license. It records the claim the operator was making: “this component came from X.” If redistribution rights were never verified, the honest modern page describes the component and refuses to ship the ZIP.
A credits page that is only a link farm of weather gadgets has failed those three readers. A credits page that lists software, template, data, and media as separate blocks has a chance.
Software, templates, and data are different citations
Mixing them is the usual error, because they all appear as URLs.
Station and helper software. Name the program that read the logger, the version if known, and any preprocessor that sat on the port (virtual serial helpers, vendor live monitors). This citation belongs with the configuration record as well. Credits should not be the only place a version appears, but they should not contradict configuration.
Web templates and scripts. Name the template family and the local fork. “TWS” on this host meant TNET Weather Station files, not a vendor product. Community PHP for forecasts, NOAA HTML, and sparklines should be credited to the author the operator actually used, with a link to the author’s current site when that site still exists. Do not credit a fork as if it were the upstream.
Data and official products. NWS forecasts, NOAA monthly forms, NEXRAD imagery, and METAR backups are data sources. They need a source name and a statement that the hobby site is not the authority. Heat index and similar values are derived and should be labeled as such, with a method citation, not as a second thermometer.
Media. Webcam stills, gallery photos, and slideshow images need a photographer or a collection name. A visitor-center photo is not station data.
Infrastructure mentions. Hosting OS, UPS brand, and graphics-tool names are optional. They rarely belong in a climate citation. If they appear, label them as website furniture.
The recovered credits page also mixed in unrelated “weather facts” filler. That filler is not citation. A credits URL that teaches barometric pressure in the same breath as a template author is two articles colliding. This rewrite keeps the collision from happening again.
Distinct from /aboutus.php
/aboutus.php answers: who operated the station, where it was, how to contact. Coordinates, a private-station disclaimer, and a map belong there.
/tws-credits.php answers: whose software, templates, images, and official products the pages depended on.
If you put credits only on About, a later archivist looking for “the CarterLake attribution” has to read a location essay. If you put operator identity only on Credits, a later archivist looking for Mesa coordinates has to read a software list. Inbound links to this host used both URLs for those two jobs. They stay two jobs.
A third neighbor, /webtools.php, listed graphics and workstation tools used to build the site. That is adjacent to credits but not identical: tools-used is a workshop inventory; credits is the public citation set that should travel with the pages.
How to write durable attribution
Durable credits survive domain lapses, template upgrades, and preservation.
- Cite works, not vibes. “Weather Display, station software” is a citation. “Thanks to the weather community” is not.
- Keep upstream and fork distinct. If you modified a Saratoga script, say so. Do not publish the modified file as if you were the original author, and do not publish the original file if you lack redistribution rights.
- Date the list. Software versions change. A credits page without a “last reviewed” date implies the 2007 stack still runs.
- Link to living documentation, not to a parked personal URL, when an official page exists. Weather Display and Saratoga Weather Scripts are examples of the kind of upstream that should be checked rather than copied.
- Credit data sources every time they appear, not only on the credits page. A forecast page should still say NWS. Credits is the index, not a license to omit labels elsewhere.
- Do not imply endorsement. Listing NWS or a vendor is not a partnership. The same rule applies to Starlink and SpaceX on the modern TNET site: factual product names, no implied endorsement.
When TNET preserves a historical URL, the same rules apply to the new article: original prose, no copied template text, no rehosted package of unclear rights.
Practical checklist
- Maintain a credits URL separate from About and from Tools Used.
- Group entries: software, templates/scripts, data/official products, media.
- Put versions and dates where they affect interpretation of the observations.
- Remove filler facts that belong on an FAQ.
- When a third-party project dies, keep the name and mark the link as historical; do not replace it with an unrelated sponsor.
- Never use the credits page as a live equipment advertisement for a station that is not running.
Modern relevance
Provenance is the same problem whether the object is a 2007 PHP template or a public weather field used in connection research: say what the source was, who produced it, and what kind of statement it is. TNET’s public note on that discipline is data sources, quality controls, and methodology, which is the primary modern destination from this URL. It does not list historical PWS credits, and this page does not describe TNET internals.
How observed, modelled, and derived information are distinguished in the service is how the service works. The site-history hub and the legacy hub index About, credits, sitemaps, and other continuity pages as separate articles rather than one blended “history” dump.
Related historical pages: About, the template sitemap, and tools used.