X
Tech

Free is not always open, open need not be free

Finding open source code in shareware can be hard work, and it's best that open source developers not talk about their specific identifiers publicly, lest they be edited out.
Written by Dana Blankenhorn, Inactive

Before most of us had heard of FOSS there was shareware. (Image close up from Appistry.)

Shareware was distributed free, often on floppy disks (ask your dad what they were). You could use it but you were expected to pay for it if you liked it.

Business models differed. Some shareware locked up if you used it too much. Some put ads on your screen until you paid. And some just kept running, hoping that eventually your guilt would lead to a check.

We eventually called this last type of software freeware. And many people, to this day, mistake freeware for open source. It's not.

Free is not always open, and open need not be free.

As our own Dan Kusnetzky writes today, Appistry is currently playing this free-but-not-open game to gain market share. He calls it "an interesting gambit," especially as they're using many open source buzzwords in their marketing.

Richard Stallman's word for it might be unprintable. (Even if his beard gets as white as mine, it won't be ho-ho-ho.)

This news emerged just as the Software Freedom Law Center has released its latest white paper, on shareware.

The paper describes, in plain English (strange language for lawyers to use) how shareware fits inside the open source universe.

If you expect people to pay for your shareware, writes James Vasile, that's OK, even if you distribute it under the GPL. Require a payment, or leave out any of the GPL's freedoms (editing, redistribution, etc.) and you have a problem.

The paper then describes all the ways you can find open source code in shareware and thus place it under the protection of a license. Unique strings, Easter eggs, cutting room scraps, digital watermarks, and bugs can all work.

Finding open source code in shareware can be hard work, and it's best that open source developers not talk about their specific identifiers publicly, lest they be edited out. The aim is to keep what should be freely available from falling into the proprietary realm and becoming unavailable.

Anyone want to try this kind of analysis on Appistry?

Editorial standards