Hi from the inaugural Hacks/Hackers NYC Hackathon, where the caffeine has been replenished and the coders are getting down to geekery.

For the full-real time experience, you can follow @opensourceathon and watch #hackshackers. I’ll be blogging notes from the day, recapping the speakers’ presentations and chronicling what the programming teams are working on.

We started the day with a crisis: Coffee shortage! Fortunately, Jenny 8. Lee charged into the fray and returned with provisions. Lots and lots of fully-caffeine-loaded provisions (we unanimously ruled decaf “not coffee”).

Armed with java and bagels, we gathered for the opening presentation from Aaron Williamson, counsel to the Software Freedom Law Center.

Open-source licensing 101 (an overview of Aaron’s remarks, direct quotes from him marked)

All open-source licenses give you the right to copy, modify and redistribute code. They don’t limit who can use the code: It’s not an open-source license if you can’t use the software commercially, or for military applications.

The place to find licenses is at the Open Source Initiative website. They come in two main flavors, “copyleft” and permissive.

A copyleft license requires all new code derived from the work to also be released as open-source. It follows the philosophy of Richard Stallman (a “free software moralist”), and the most popular copyleft license is the GNU General Public License (GPL).

Permissive licenses don’t place restrictions on derivative work. You can take the code, build something new with it, and keep that as secret and proprietary as you like. Products derived from permissively licensed open-source software are ubiquitous these days; Apple used BSD as the basis of its Unix-based OS X.

Those are the two camps, but there are a huge range of options along the way, including “weak copyleft” licenses (which allow parts of programs to be incorporate into others; LGPL is a common one) and distinctions within the permissive camp, especially around patent protections.

“Patents have become an enormous problem for software developers. Anyone who owns patents sort of by definition has a lot more money than you do.” A bunch of modern licenses — notably, Apache 2.0 — pass on patent licenses from all the contributors. “In many ways these are symbolic gestures. If Oracle comes along and sues me, unless Oracle contributes to that program I don’t have a patent license.”

Communities tend to coalesce around a preferred license; for example, Ruby coders have adopted the highly permissive MIT License (which is “badly written” — too much passive voice! — “but a fine license”). You’re free to adopt any license you like for your own products, but you’ll be swimming upstream if you ditch the license the community knows and likes: “If you damn the torpedoes and go GPL, the trade-off will be fewer people using your code.”

Other notable licenses: The Affero General Public License (AGPL) tries to solve a loophole. The GPL (which was first used in the late ’80s) is linked to physical distribution of a software program. But now many apps are used over a network. The AGPL explicitly extends the license’s protections to software accessed that way.

Sick of TLAs and legal minutia yet? If so, check out WTFPL, which is exactly what it sounds like. The FAQ is excellent: “What the $%#! is not clear in “DO WHAT THE $%#! YOU WANT TO?” (that is an, er, edited version). Aaron’s take: “It’s a valid free software license as far as I’m concerned.”

Aaron did a quick run-through on public domain issues, starting with the two ways works can become public domain: 1) the copyright expires, or 2) the creator explicitly abandons their copyright.

Route #1 “almost never happens now — the lawyers and Senators who work for Disney will keep extending copyright indefinitely.” Route #2 is harder than you’d think. Some jurisdictions — primarily in Europe, especially Germany and France — have strong “moral rights” stances and basically don’t let a creator waive all rights forever. “If you’re really hardcore public domain, your best option is Creative Commons 0 license. It’s unclear whether this is effective in all jurisdictions.” Aaron’s view: “I personally wouldn’t recommend a public domain license for code like Creative Commons — I think it’s admirable, but I would go for a highly permissive license if that’s what you’re after.”

Next up, Q&A, starting with the question “What if there’s code sitting around on github or some such with no license attached?” Aaron’s answer: “All rights reserved. If there’s no license, you have to assume full copyright.”

Q: “What does the noncommercial Creative Commons license block?” Aaron’s answer: “Nobody knows what it prohibits, including the Creative Commons .” [note-taker’s interjection: This is a constant headache for reporters — does editorial use of an image for journalistic purposes on a for-profit news site violate noncommercial rules?] “I consider noncommercial licenses a baby step for people who are not really comfortable with free culture to wade in a bit.”

Parting words: “License proliferation is a problem. I strongly recommend that people choose widely used licenses.”

Open-source development 101

Next up was presenter Jeremy Ashkenas, lead developer at DocumentCloud.

Jeremy’s run through of open-source basics started with the question “why do it?” One answer: “The more you give away, the more you get back,” in bug reports and code contributions for things like cross-browser compatibility.

One definition of a good open-source project is one that’s being actively used, maintained and patched. “Most open-source projects are failures by that metric.” It raises an existential question: “What are doing when you write software and the code isn’t run and isn’t read? In what sense are you programming? Is it just a kind of strange essay you’ve written for yourself?”

Before you start contributing to a project, learn its ground rules. For example, the CoffeeScript project he works on has a few “golden rules” including “no special functions will be added to the runtime.” Know the rules so you don’t spend a week coding a feature that can’t be used.

Every project needs a homepage, which can be as basic as a README file or as fancy as a full website. Example of how not to do it: Lucene. “If you don’t know what it is, you’re not going to find out from this page.” One that does it well: Django. It explains the project, who it’s for (“perfectionists with deadlines”) and has a prominent download link.

Documentation is critical. YARD is a good tool for Ruby; Spinx is good for Python. Examples of well-documented projects with good homepages: Sinatra, Vows.

Code has “a dual audience: You’re not just writing for the machine.” Hence the literate programming movement, which pushes for elegant, well-documented code other humans can read. “The whole history of programming has been that as the machine gets faster or smarter, every year we can speak more clearly to the reader.”

Docco is a documentation generator to help out on that front. It’s been ported multiple times, including Rocco (Ruby), Pocco (Python) and, for the hard core, Shocco (shell).

At the end of Jeremy’s talk, the coders scattered off to their teams. I’m about to go poll the groups on what they’re working on; that update will come later today.

Shout-out to our sponsors, Google and OpenPlans, which is hosting us in its palatial Soho penthouse. Want to work amid panoramic views and a roof garden? They’re hiring.

-Notes by @StacyCowley, released under WTFPL