Licensing Basics for Transfer Tools

The installer shows a wall of text and a button that says "I accept." Nobody reads the wall. I include myself, and I have helped write one. Most administrators meet software licensing exactly three times. They meet it at that button and at a renewal where a number has changed. Then a letter arrives asking them to prove how many copies they are running. Between those moments licensing is invisible. That is how an estate ends up with a transfer server nobody can prove is licensed. It also ends up with a client on every desktop under terms nobody checked, and a "free" tool that was free for personal use only.

A license is the set of permissions and conditions under which you may use a piece of software. This article, part of our Open Source vs Commercial series, is the plain-words version of what an administrator needs. It covers the open source license families and what each typically permits and requires. It also covers the commercial models and what "a server" or "a user" actually counts, and compliance hygiene without a legal department. It is education, not legal advice. The license text in front of you always governs, and when money or redistribution is involved, someone qualified should read it.

We sell commercial transfer software under commercial licenses, so we have a stake in one side of this. We have tried to write the open source half as clearly as the commercial half. The compliance section applies to us as much as to anyone.

Why an Administrator Needs to Understand Licensing at All

Copyright means that, by default, you may not copy or run someone else's software at all. The license grants permission, and its conditions are the price. For open source, the price is usually a few obligations that only bite in specific situations. For commercial software, it is money plus restrictions on how much you may run.

Three situations turn licensing from invisible to urgent:

• Installing or expanding. A second transfer server for failover, a test instance, a client on a hundred desktops, a container image with an SSH server baked in. Each may or may not be covered by what you already have.
• Redistributing or embedding. This includes shipping a client installer to a partner or bundling a transfer library inside an application you deliver to customers. It also includes modifying an open tool and sharing the result. This is where open source obligations actually apply.
• Being asked to prove it. This could be a vendor's license review, an internal audit, a customer's security questionnaire, or a due-diligence exercise. All ask "what do you run, under what terms, and can you show it?"

The rest of this article gives you enough vocabulary to handle all three calmly, which is more than the "I accept" button ever did.

Open Source License Families in Plain Words

Open source licenses grant everyone the right to use, study, modify, and share the software, with conditions. The conditions distinguish the families, and there are essentially two.

Permissive licenses ask very little. You may use the software for anything, modify it, and include it in your own products, including closed commercial ones. The typical requirement is that you keep the copyright notice and license text with any copies you distribute, and that you do not claim the authors endorse your product. The long-standing BSD-style and MIT-style licenses are the familiar examples; OpenSSH, for instance, is distributed under a permissive BSD-style license.

Copyleft licenses add a reciprocity condition. If you distribute the software or a modified version, you must make the corresponding source code available under the same license. In the stronger variants, the same condition applies if you distribute a program that incorporates it. The GPL family is the long-standing example. The practical effect is that copyleft software stays open as it spreads. What copyleft does not do, and this is the point most often misunderstood, is restrict using the software. Running a copyleft transfer client on every desktop in your company, or a copyleft server in production, triggers nothing. The conditions attach to distribution, and internal use is not distribution.

The table below summarizes the families alongside the "free but not open" categories covered next, because administrators meet them all in the same download folder.

For transfer tools specifically, the copyleft question almost only arises in application development. If your developers are embedding a transfer library in software the company distributes, the library's license family decides what they owe. The article transfer libraries in applications covers that decision. For everything else (servers you run, clients your staff use, scripts that call open tools) you are using, not distributing, and the obligations are close to nil.

"Free" Is Not the Same as "Open Source"

The download folder does not label its contents, and three kinds of "free" are routinely confused with open source. Freeware is commercial software offered at no charge under a commercial license. You may run it as the text allows, but you have no rights to the source and the terms can restrict where and how. Free for non-commercial use editions are freeware with a boundary: at home, yes; on a company server, no, however small the company. Evaluation editions grant full functionality for a fixed period so you can test, and typically forbid production use after it ends.

None of these is a trick; they are honest arrangements when read. The commercial example we know best does both. Sysax Multi Server offers a free Personal edition for non-commercial use and a free thirty-day trial of the full product. A home lab running the Personal edition is inside the terms. A business running it as its partner-facing server is not. The fix is simply to buy a license or use the trial period to decide. The failure mode is never malice. It is an administrator who saw "free," installed, and forgot, which is what the inventory in the compliance section prevents. Trial editions have a talent for becoming production servers; nobody decides it, it just happens by Thursday.

Commercial Licensing Models

Commercial licenses differ along two axes: how you pay over time and what is counted. Both feed the ledger in the hidden costs on both sides, and both are worth understanding before a vendor presents a quote.

Perpetual versus subscription. A perpetual license grants the right to run a given version indefinitely. It is typically paired with an optional maintenance or support term that provides updates and support while it lasts. When maintenance lapses you keep what you have but stop receiving new versions. A subscription grants the right to run the software only while the subscription is active. Lapse and the right ends, sometimes with the software disabling itself. Perpetual favors stable estates that upgrade rarely; subscription favors predictable budgeting and always-current versions. Neither is inherently better, but the difference at lapse time is enormous, and it belongs in your exit planning.

Editions. Most commercial transfer products come in tiers, with features gated by edition. The gate you care about is the one between the edition you can afford and the feature your next partner requires. Get the edition feature list in writing and check it against your requirements before, not after, purchase. Our choosing a transfer server series treats edition gotchas as a first-class criterion.

The counted quantity, the license metric, is where most compliance problems and hidden costs originate. The table below lists the common ones and the definitional questions each raises.

What Counts as a Server, and What Counts as a User

The definitional questions in that table are not pedantry. They are where real organizations discover they are out of compliance without having done anything that felt wrong.

Consider the server metric. A team buys one server license, then builds the sensible things. It builds a warm standby, a test instance for partner regression tests, and a container image so developers can run the server locally. Under some license texts that is one server. Under others it is four, or "one production plus any number of non-production," or "two, because the standby counts only when active." Each of those readings exists in real contracts. The only safe practice is to ask, in writing, before building the second instance, and to keep the answer with the license.

The user metric is worse, because transfer servers have unusual users. A partner-facing server may have twelve human administrators and three hundred partner accounts that belong to other companies. It may also have forty service accounts used by scheduled jobs. And it may have anonymous or browser-based uploaders who never log in at all. A "per user" license can count any subset of those. Before buying, list your account types and ask which ones count. Before renewing, count them again, because partner accounts grow quietly. Directory-integrated authentication adds a twist: if the server accepts any domain account, is every domain account a licensed user? Settle it in writing, and file the answer somewhere a successor can find it, which rules out your inbox.

Compliance Hygiene Without a Legal Department

License compliance for a small IT team reduces to three habits. Know what you run, keep proof that you may run it, and review both on a schedule. None requires a lawyer. All require a place to write things down and a person who owns it.

Bluewater Bank acquired the first habit under pressure. A large customer's due-diligence questionnaire asked for every file transfer tool in use and the license each ran under. The honest first answer was "we will need three weeks." The inventory, once built, found a trial edition that had been the production server for fourteen months. It also found a free-for-personal-use client on ninety desktops, installed by a help desk that had reasonably read "free" as free. Nobody had done anything that felt wrong. They bought two licenses, standardized the client, and sent the questionnaire back late, which the customer minded less than the alternative.

Knowing what you run is the same inventory that security, audit, and sprawl cleanup all need. The article discovering every server and script shows how to build it. And the transfer inventory gives it a home. For licensing, each tool needs one record. Here is a template that fits in a spreadsheet row or a text file:

TOOL LICENSE RECORD — one per product in the estate

Tool:                 (server, client, library, or script dependency)
Where installed:      hosts / desktops / images, with counts
Owner:                named person responsible for this record
License family:       permissive OSS / copyleft OSS / source-available /
                      freeware / non-commercial / evaluation / commercial
License text:         path or link to the exact text as it applied when
                      acquired (licenses change; keep the one you agreed to)
Commercial terms:     perpetual or subscription; maintenance end date;
                      edition; metric (server / user / connection / site)
Metric definition:    the vendor's written answers: what counts as a
                      server, a user, a site; non-production rules
Entitlement:          quantity licensed vs quantity in use, with date
Proofs:               invoice, license key, entitlement email, contract
Distribution?         do we ship this to partners or customers, or embed
                      it in software we deliver? (if yes: legal review)
Renewal / review:     next date, and who receives the reminder
Last reviewed:        date and initials

The second and third habits are the checklist below. It is deliberately short, because a long checklist is one nobody runs.

LICENSE COMPLIANCE HYGIENE — CHECKLIST

KNOW WHAT YOU RUN
[ ] Every transfer server, client, and library has a license record
[ ] The inventory is rebuilt from discovery, not memory, at least yearly
[ ] "Free" tools are classified: open source, freeware, non-commercial,
    or trial — and non-commercial and trial editions are not on company
    production systems

KEEP THE PROOFS
[ ] License keys, invoices, and entitlement emails are stored where a
    successor can find them, not in one person's mailbox
[ ] The license text as it applied at purchase is kept with the record
[ ] Metric definitions are in writing from the vendor, filed with the key

STAY INSIDE THE COUNT
[ ] Server, user, or connection counts are re-measured before renewal
[ ] Standby, test, and container instances are checked against the
    non-production rules, in writing
[ ] Partner and service accounts are included in any per-user count

HANDLE CHANGE
[ ] Renewal and maintenance end dates are on a shared calendar with a
    reminder well before they lapse
[ ] Redistribution or embedding of any open source component gets a
    review before it ships
[ ] A named owner exists for the whole record set, and a second person
    knows where it lives

Run the checklist once a year and at every purchase, renewal, or major change. Ongoing vendor monitoring is a natural home for the commercial half. A client standard (our client standardization series) is a natural home for the desktop half. A standard client with a known license removes a hundred unknown ones.

When Someone Asks You to Prove It

A commercial vendor may, under most contracts, ask you to verify your deployment against your entitlement. This is sometimes called a true-up or a license review. Internal auditors and customers running due diligence ask similar questions without the contract. The article answering security questionnaires covers that direction. The experience is calm or frantic depending entirely on whether the records exist.

With records, the response is a report: here is the inventory, the counts, the proofs, the metric definitions you gave us in writing. Discrepancies get resolved by buying the difference or removing the excess, and the written definitions settle arguments about what counted. Without records, the response is a scramble to discover your own estate under time pressure. Every ambiguity resolves in the vendor's favor because you cannot show otherwise.

Open source rarely produces a letter, but it produces questions from a different direction. Security scanners and customer questionnaires increasingly ask for a list of open source components and their licenses. The same inventory answers them. And if your organization distributes software, the copyleft question can arrive from a customer's lawyer rather than from the project. That is one more reason the "Distribution?" line in the record template is there.

The Version to Tell a Colleague

Open source licenses come in two families: permissive ones that ask you to keep the notices, and copyleft ones that ask for source when you distribute. Neither restricts simply running the software, which is what an administrator mostly does. "Free" is not always open source: freeware, non-commercial editions, and trials are commercial licenses with boundaries. Commercial licenses differ in how you pay over time and in what they count. The definition of what counts is the thing you are actually buying. Compliance is three habits: know what you run, keep the proofs, and review on a schedule. None of it requires reading the wall of text at install time, though it would not hurt.

The licensing metric is the engine behind the growth row of the hidden costs on both sides. Support entitlement is tied to the terms described in support realities. Most estates hold both open and commercial tools. When yours does, mixing open source and commercial tools sensibly shows how to keep one inventory across both. And once more, for the record: this is education, and the license in front of you is the authority.

Frequently Asked Questions