Draft Licensing Agreement for SCA Software Developers

TL;DR: If you write or manage software for the SCA, I’d love to get your feedback on this proposed license agreement intended to document the Society’s ability to continue using and maintaining the software even if you someday become unavailable.

Given the high proportion of technical professionals in the Society’s ranks, it is no surprise that the SCA has a long history of informal software development: folks developing small custom applications to facilitate some part of their office’s or local group’s operations. However, this process has by-and-large been uncoordinated, and policy for it has been slow to coalesce.

One recurrent issue in this area has been the lack of clear licensing practices. In a few cases, copyright has explicitly been transferred to the Society, but in the majority of cases the issue has not been considered, leaving the copyright in the hands of the original developer. In most cases, there is no written license agreement, which is usually fine while the original developer remains involved in local activities, but can become problematic if they move away or drop out of Society activities, as nobody knows for sure if the group has the right to to continue using the software, to make changes to it, or to share it with other branches of the SCA.

There are also a few tragic cases in which some kind of interpersonal dispute or falling out leads to someone abruptly quitting their local group and taking their software with them; obviously, in the absence of any agreement to the contrary, they have the right to do this, but it can cause a great deal of disruption if the branch or office has adapted their procedures to be dependent on that software. (And in other, less-clearly documented cases, it’s possible that the threat that someone could abruptly withdraw access to the software they had created can give them an inordinate amount of leverage in their group’s governance.)

For several years, I’ve been encouraging various kingdom and Society officers to get ahead of this problem by asking developers to sign agreements that grant the Society a license to continue using and updating their software in perpetuity. I’ve drafted several versions of such an agreement, and managed to get one included in the Release Forms Handbook that was published a year ago.

Unfortunately, there are several problems with the version that was published in the Release Forms Handbook. Notably, the published version provides for a complete copyright assignment, under which the original developer gives up all rights to their work; a fair number of developers feel that this is over-reach for a volunteer-led effort in which people are writing code on their own initiative and without compensation. (The published form also includes a few typographic errors and formatting oddities that were introduced when the forms were converted to MS Word format.)

I’ve created an updated version of this agreement which attempts to address those concerns. My thanks to Iohann der Vuhs of the Outlands for his feedback, as well as the other members of the webministry who have reviewed and commented on this draft.

There are three substantive provisions in the agreement:

  • Confirms the SCA can use the code forever at no cost, including making changes in the future or sharing it with other parts of the organization.
  • Protects the SCA from copyright claims in case someone later says a developer provided code that they didn’t have rights to.
  • Insulates the developer from liability if the code malfunctions.

Hopefully, widespread use of this type of agreement might allow software developed for the SCA to be shared, reused, and improved across the organization, reducing the frequency with which similar systems (event calendars, order-of-precedence listings, martial authorization databases, etc.) are re-created by each kingdom because folks don’t know if they’re allowed to repurpose code that was written elsewhere.

This proposed agreement doesn’t in itself create any kind of sweeping policy; it simply provides a way of memorializing one person’s grant of a license to some of their work. (Independently, I do think that SCA offices and groups should have a practice of asking developers to execute such an agreement — and if someone declines to do so, the SCA can make an informed decision as to whether they want to proceed without it — but I’m not in a position to make or enforce such a policy.)

If you have any concerns about this draft agreement or suggestions for how to improve it, I would love to hear about them!

[Update, Nov 24:] A couple of people have asked me why this bothers to include provisions other than open-source — given that open-source licensing addresses the SCA’s needs, and doesn’t have any real drawbacks, shouldn’t we just encourage everyone to choose that approach for all SCA projects? As someone who has both written and benefitted from open source code, I certainly understand this perspective, and I would encourage anyone starting a new project to choose this option.

However, there some people who have limited exposure to the open-source world find the idea of open-sourcing their code to be intimidating. My impression is that the two biggest thoughts that discourage people from making their code open source are:

  • “I wrote this code for one specific situation and I can’t imagine that anyone else would ever want to use it, so it’s easier to not go through any extra hassle.”
  • “I wrote this code in a quick and dirty fashion, and I know it’s not perfect, so I don’t want to post it publicly where other people might judge it harshly.”

I’d love to educate folks to the point where they get over those barriers and choose to open source their code, but on a practical level I care more about actually making their code properly available to and within the SCA, and so I have no objection to providing a non-open-source route that still addresses the SCA’s objectives, even if it doesn’t make the code available to the rest of the world.

There are also a number of cases of legacy code where open-sourcing might be very difficult; for example, the East Kingdom’s order-of-precedence database is a lightly-customized copy of one developed in Atlantia more than a decade ago. An unknown number of people have contributed bits of code to the site — at least a dozen? — and it might be impossible to track them all down and get permission to license their work under an open license. However, it still makes sense to ensure that anyone doing work on that code in the future has agreed to some kind of license… even if we can’t fix the licensing mess in a single stroke, we can avoid continuing to make it worse.

Leave a Reply

Your email address will not be published. Required fields are marked *