Sign inRegisterCheck connection

How Weather-Software Projects Were Packaged and Credited

How Weather Display and Cumulus community projects were packaged, versioned, documented, and credited, and why a public index mattered more than a file dump.

Back to PHP weather scripts and software guides

A weather-software project is more than a ZIP attached to a forum post. In the personal-weather-station community, a project meant a named package that declared its station-software target, a version, a license, a credit list, and enough documentation that another operator could tell whether the files would even parse. This article is about that release discipline. It is not a file dump, and it does not rehost historical archives.

The historical TNET Weather page at /projects was an index: Cumulus and Weather Display utilities listed by name, with a downloads section, a reference section, and links to official vendor pages. The page also said that most scripts were released under the GNU General Public License and that work was periodically suspended. Those are historical statements about how the index was run. They are not a promise that TNET Weather today maintains, supports, or redistributes those packages.

Historical context

Weather Display and Cumulus both solved the same operational problem—read a station, write files, upload a website—but they produced different file contracts. A script written against Weather Display's HTML climate reports would not read Cumulus realtime.txt. Operators therefore needed an index that said, in one place, which package belonged to which stack, which build it had been tested against, and who was allowed to copy it.

The /projects URL existed because discovery on forums was lossy. A useful parser would be posted in a thread, revised in a later reply, then replaced by a "final_v2_fixed.zip" with no license header. An index page is a weak form of scientific provenance: it binds a name, a date, a target platform, and a credit line together so that a later citation can mean something.

This article stays on that packaging problem. The scripts hub covers the taxonomy of PHP tooling problems. The Cumulus pillar covers Cumulus as station software and the historical project family as engineering overview. Individual packages such as the PHP-GD banner have their own URLs and should keep them.

What a packaged project had to declare

A community weather project that other people could run had to answer five questions on the first screen, before anyone unzipped anything.

1. Target software and file contract

"Works with Cumulus" is not a specification. The operator needed the product family (legacy Cumulus 1 versus Cumulus MX), a minimum version or build when known, and the files the package actually read: realtime.txt, a dayfile, processed web tags, Weather Display ClientRaw, or a vendor HTML report. Mixing those contracts is the most common silent failure in inherited sites.

2. Runtime contract

PHP version, GD or TrueType availability, cron or scheduled tasks, and whether the script expected to run on the public host or on the logger PC are part of the scientific setup. A banner generator that requires GD is a different instrument from a parser that only splits a text line. A Windows scheduler helper is not a web script. The historical index mixed those kinds of artifacts; a careful reading still has to separate them.

3. Version and date

Version numbers in this community were often 3.1 plus a calendar date, sometimes plus a station-software build. That pairing is the useful part. A graph package labeled for Cumulus 1.8.2 beta is a historical compatibility claim, not a current support statement. When the index listed a release date beside a version, it created a timeline that later operators could use to guess whether a file format had already changed.

4. License, in words a lawyer did not have to decode

The historical TNET index used several labels: GNU General Public License for many packages, public domain for at least one small utility, and FreeBSD License in some Cumulus-page copy. Those labels are not interchangeable. GPL requires that recipients who receive the program also receive corresponding source under the GPL's terms. A BSD-style license is permissive and does not impose copyleft. "Public domain" is a dedication, not a default. "Freeware, modify as needed," which appeared on some neighboring community pages, is not a named OSI license.

If a recovered ZIP has no license file, the honest status is unclear. Unclear is not the same as "TNET may rehost it." This site describes the workflow and leaves redistribution to rights holders or to collections that still offer the work under a stated license.

5. Credits and issue routing

A project page that named testers, the station-software author, and the graphic or forum contributors was doing citation work. It told the next operator who to ask when a field moved. It also prevented the false impression that one person invented the entire stack. Weather Display is Brian Hamilton's software. Cumulus began as Steve Loft / Sandaysoft software; Cumulus MX is now an independent open-source line with its own maintainers. TNET was a community contributor, not the vendor.

Why an index page was a research instrument

An index is easy to dismiss as navigation. For PWS software it did three jobs that a forum thread cannot.

Citation. Another site could link to /projects or to a named child such as /projects/phpggbanner and mean a specific artifact. University and hobby feeds that consumed ClientRaw or Cumulus files needed a stable name for the helper they used. That is why child URLs still exist even when the ZIP is not offered here.

Compatibility scanning. A list that shows "this package reads realtime.txt; that package reads Weather Display climate HTML" is a map of file contracts. Operators could see, before installing anything, that a Cumulus banner and a Weather Display sparkline were not interchangeable decorations.

License scanning. Putting GPL next to public domain next to "inside script" documentation forced a reader to notice that the legal situation was not uniform. A later preservation project that flattened every ZIP into one "downloads" folder would erase that information.

The historical page also linked official Cumulus product, forum, wiki, and map URLs. That pattern is the correct one: community indexes should send operators back to the vendor's current documentation rather than freeze a 2008 screenshot of it. Current Cumulus MX documentation lives on the Cumulus Wiki (last checked 13 August 2026). Current Weather Display documentation lives on weather-display.com.

Release engineering in a volunteer weather community

Professional software projects have issue trackers, signed releases, and CI. PWS projects of this era typically had a forum thread, a version string inside the PHP file, a PDF for the more ambitious packages, and a download counter. That was still release engineering. It just ran on different rails.

Documentation as a contract. A PDF or an in-script header that listed requirements (PHP 5, GD, a path to realtime.txt, Cumulus 1.8.2 or higher) told the operator what experiment they were about to run. When documentation lived only in a forum first post, it aged into contradiction: the post said one path, the ZIP said another.

Build identity. Cumulus and Weather Display both used version-plus-build numbering. Community scripts that recorded "tested on build n" were doing the same thing scientists do when they record instrument firmware. Without that number, a parsing failure cannot be classified as "operator error" versus "vendor format change."

Change discipline. The honest changelog for these packages was often one line: "updated for new WD HTML" or "requires Cumulus 1.8.2 beta." Thin as that is, it is more useful than a silent overwrite of banner.php. Format drift in vendor reports was a known event; the historical scripts hub already noted an averages/extremes extractor that stopped working after Weather Display changed its HTML.

Distribution channel. The historical site used ordinary links and, on some pages, click-tracker URLs that counted downloads. Those tracker links are not used here. A download count is not a scientific result, and a tracker URL is not a stable citation. The child path /projects/downloads remains as a historical address; it is not a software mirror.

Suspension as metadata. A banner that said projects were suspended for lack of time is itself a release signal. It tells a later reader not to treat the index as a living support desk. Preservation should keep that signal rather than replace it with fake "current version" tables.

GPL versus unclear: a practical reading

Operators who still have copies of these files often ask whether they may publish a modified banner script on a new host. The answer depends on the license that traveled with the file, not on the fact that a Wayback snapshot exists.

  • GNU GPL. If you received a GPL-licensed program, the GPL governs your distribution of that program and of modified versions. You do not need TNET's permission to exercise rights the license already granted, and TNET is not asserting that every file in a recovered tree was in fact GPL. Check the headers in the copy you have.
  • BSD / FreeBSD-style. Permissive licenses typically require retention of copyright notice and disclaimer. They do not force you to GPL your surrounding website.
  • Public domain label. Treat it as a dedication only if the file actually says so. Do not infer it from "free download."
  • Unclear. Describe the algorithm, rewrite from first principles if you need the function, or use a maintained project with a stated license. Do not paste recovered PHP into a public repository "for backup."

Saratoga Weather's template and script collection is the maintained continuation of a large part of the Weather Display PHP tradition and is the right first stop when the question is "what can I run safely now?" rather than "what did a 2008 ZIP contain?"

Practical checklist for reading an old project index

  1. Separate stacks. Mark each named project as Weather Display, Cumulus, generic PHP, or desktop utility. Do not install across stacks.
  2. Copy the version line into your station notes. Include the vendor build it claimed to support.
  3. Find the license in the package, not only on the index page. Index copy and file headers sometimes disagreed.
  4. Record credits. If you reuse an idea, name the authors you can verify. Do not imply vendor endorsement.
  5. Ignore download counters and PayPal lines. They are historical site furniture, not measurement data.
  6. Do not follow old .click tracker links. They are not documentation.
  7. Prefer official current docs for how Cumulus or Weather Display actually write files today.
  8. Keep child URLs as citations even when the binary is gone. The name is the scholarly object this preservation effort can honestly keep.

What still applies

Release engineering did not become obsolete when FTP weather sites aged. Anyone who publishes a parser, a banner, or a template still needs a target contract, a version, a license, and a credit list. The difference is that the default host is no longer PHP 5 on shared FTP, and the default documentation home for Cumulus is a wiki plus GitHub rather than a single vendor product page.

TNET does not maintain Cumulus or Weather Display, does not offer the historical ZIPs, and does not claim the original authors' copyrights. The /projects URL remains because the index itself was part of how the community documented its instruments.

TNET research bridge

Packaging and provenance are the same discipline whether the object is a 2008 PHP banner or a public weather record used in later research. TNET's note on data sources, quality controls, and methodology is the modern place to see how freshness, licensing, and source identity are treated for the records behind connection research.

Related historical pages: the software and scripts hub, the PHP tooling-layer article, the Cumulus overview, and the Weather Display publishing article. The PHP-GD banner remains a named child at /projects/phpggbanner for readers who need that specific artifact's address.

Sources