Choose your licence, Luke!

Mateusz Kulewicz

Open Source community is all about sharing. If you take a look at the definition of Open Source software, it is computer software with its source code made available with a licence in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose (source). I bolded the word 'licence’ as this is quite an important part of the definition. Github terms of service state the following:

By setting your repositories to be viewed publicly, you agree to allow others to view and „fork” your repositories (this means that others may make their own copies of your Content in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub’s functionality. You may grant further rights if you adopt a license.

It basically means that while people can fork your repository, they aren’t allowed to experiment with it, modify it or share it in different locations.

How many participants have licences?

I wrote a Python script to check that (MIT-licensed ;)). Let’s take a look at the stats:

Licence Count
MIT 114
GNU GPL 46
Public Domain 1
GNU Affero GPL 3
GNU LGPL 2
NO LICENCE 492
EMPTY REPO 155
Apache 16
BSD 3-clause Licence 3

Out of 832 repositories at the moment of writing, 492 (59%) had some code but didn’t have any licence yet (there might be some that used non-standard locations for licences – I checked for the existence and content of LICENSE file in root directory). 155 other repositories (19%) still are empty. That means that only 22% of contest code is now licensed in a way that is actually Open Source.

 

Which licences do people use most often?

How do I choose a licence?

The simplest option is MIT – you basically allow others to use the code as they wish, also in commercial projects. A companies-friendly licence is also Apache Licence. If you want to force others that use your code (i.e. as a library) to also publish their code under a compatible licence, think about GNU GPL. That might mean that commercial entities will hesitate from using your code. At the company I’m working at we’re always making sure we don’t use GPL licenced libraries in our projects. It doesn’t mean though that you cannot use GPL-based software (such as GIMP or NetBeans) in the commercial environment without sharing your results – it’s only if you use it as a dependency.

If you need better guidance, take a look at choosealicence.com.

Feel free to correct me if I got anything wrong, and, for those of you that haven’t done it yet, choose a licence, Luke!

Matchlogger: a slow start

Mateusz Kulewicz

As the Polish-speaking followers (quite likely 100% of all my followers) already know, I am taking part in a software development contest called „Daj się poznać” where the aim is to develop an open-source application for three months and blog about it. The contest starts today, so this is the moment when many participants write about their aims. So, my project is…

Matchlogger

A web-based app that can be used by players, referees, and supporters to mark matches they either took part in or watched. The aim is to enable the users to log their matches in various disciplines and add data they deem important, for example, minutes they played, goals they scored, match result, attendance… The idea is based a bit on a now-defunct website called footballfans.eu where the functionality was fairly limited and the service closed down a few months ago, but extends it not to include only supporters and only of teams that play in higher leagues.

As for the technology stack – Spring Boot is my backend choice for this project. I still consider several options for the frontend, but one that is now on my spotlight is Vue.js. I’ll likely decide on the approach here in several days. The database will be using MySQL.

First steps are already done. Today I set up the project using Spring Initializr. While most chosen dependencies were fairly standard, the one that required some extra configuration was Liquibase – the library for database versioning which I’m going to use from the very beginning. As often with Spring Boot, also this time it was a one-liner in the configuration file. The empty changelog file also was needed to be created at the referenced location.

After today, the application can be run using mvn spring-boot:run and starts up correctly with Basic auth as default security setting. Not much can be seen, though:

The code is available at Github. I’ll be using Github issues to take care of the backlog and Toggl for time logging. For the first deployment, I want to have a functioning login (likely Google- or another provider- based).