It's never nice to know that you've been violating the GPL in some form. Far better, instead, to know how to not violate the GPL in the first place -- which is the premise behind the Software Freedom Law Center's new guide to same, "A Practical Guide to GPL Compliance".

The guide (available as HTML, PDF or PostScript) tackles the subject of GPL compliance from several fronts -- best practices to employ within your organization when using GPLed software; how to create a GPL-compliant distribution; and what to do if someone does come a-knockin' with word that you've tripped up. (One, don't panic; two, communication will go a long way.)

One piece of advice I haven't seen communicated very often, and something I agree with completely: avoid a "build guru":

Too many software projects rely on only one or a very few team members who know how to build and assemble the final released product. Such knowledge centralization not only creates engineering redundancy issues, but it also endangers GPL compliance, which requires you to provide build scripts. Avoid relying on a "build guru", a single developer who is the only one who knows how to produce your final product.

As I see it, this is as bad as trusting any set of internal IT operations to one person who doesn't document his work and leaves you with a terrible mess to clean up if/when he leaves.

These types of guides are documentation -- but instead of documenting how to use a particular program, they're documenting the operations of the culture of open source. That culture's got a reputation for being insular and difficult, and the more guides we have like this (a la Lonely Planet: Open Source, maybe?) the easier that territory will be for the rest of us to enter.

The hard part about this documentation is that someone has to actually sit down and write it. Documentation has always been one of those jobs that everyone needs to have done, but few actually stick their necks out to do it. And even if you do, there's no guarantee you'll end up with anything coherent or useful. It's an area where a lot of work remains to be done -- not just in terms of writing such material, but fostering environments and attracting talent for writing it. A piece of documentation is good, but to have a system where good documentation can be produced reliably and consistently is even better.