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.
To see which licenses are free licenses, see the GNU license list. Most “open source” licenses are free, but some open source licenses are nonfree because they are too restrictive.
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.
