Why hackathons should insist on free software

Hackathons are an accepted method of giving community support to
digital development projects. The community invites developers to
join an event which offers an encouraging atmosphere, some useful
resources, and the opportunity to work on useful projects. Most
hackathons choose the projects they will support, based on stated
criteria.

Hackathons fit the spirit of a community in which people take an
attitude of cooperation and respect towards each other. The software
that accords with this spirit is free (libre) software, free as in freedom.
Free software carries a license that gives its users (including
programmers) freedom to cooperate. Thus, hackathons make sense within
the free software community. Hardware
design projects also can and ought to be free.

Respect for freedom can't be taken for granted. On the contrary, we
are surrounded by companies that shamelessly release proprietary
(nonfree) software, available for use only to those that will yield to
their power. These companies develop software as a means
to dominate and control others.

These companies' harmful success inspires young developers to follow
their example by developing their own programs or hardware designs to
dominate users. They sometimes bring their projects to hackathons,
seeking the community's support while rejecting the community's
spirit: they have no intention of returning cooperation for
cooperation. Hackathons which accept this undermine the community
spirit that they are based on.

Some perverse hackathons are specifically dedicated to aiding the
computing of certain companies: in some cases, European and Canadian banks, and
Expedia. While they don't explicitly say, the announcements give the
impression that they aim to promote development of some nonfree
software, and that attendees are meant to help these non-charitable
projects.

Those examples show how far down the slope hackathons can slide.
Let's return to the more common
case of a hackathon that is not specifically commercial, but accepts
projects that are proprietary.

When a developer brings a project to a hackathon, and doesn't say
whether it will be free, that is not overt opposition to the community
spirit, but it undermines that spirit. Hackathons should strengthen
the community spirit they are based on, by insisting that hackathon
projects commit to release in accord with that spirit.

This means telling developers, “So that you deserve our support and
help, you must agree to give the community the use of your project's
results in freedom, if you ever consider them good enough to use or
release.”

As an individual hackathon participant, you can support this
principle: before joining in any hackathon project, ask “What license
will you publish this under? I want to be sure this will be free
(libre) before I join in developing it.” If the developers of the
project say that they will choose the license later, you could respond
that you will choose later whether to participate. Don't be shy—if
others hear this discussion, they may decide to follow the
same path.

Firmness by individuals has an effect, but a policy of the hackathon
itself will have a bigger effect. Hackathons should ask each
participating project to pledge to follow this rule:

If you ever release or use this code or design, you will release its source
code under a free (libre) license. If you distribute the code in executable
form, you will make that free (libre) also.

Many hackathons are sponsored or hosted by schools, which is an
additional reason they should adopt this rule. Free software is a
contribution to public knowledge, while nonfree software withholds
knowledge from the public. Thus, free software
supports the spirit of education, while proprietary software opposes
it. Schools should insist that all their software development be
free software, including that of hackathons they support.