Kiepski pierwszy dzień w pracy

Ktoś miał wczoraj bardzo zły dzień. Młodszy programista pierwszego dnia pracy w nowej firmie przez pomyłkę… usunął bazę produkcyjną tej firmy. Został natychmiast wyrzucony z pracy, a CTO poinformował go, że najprawdopodobniej w sprawę zaangażowany zostanie dział prawny, bo przywrócenie backupów okazało się problemem.

Ze strony programisty błąd nie był zbyt duży. Skrypt, który dostał, aby przygotować mu bazę testową, na koniec zwrócił dane bazy danych. Programista wziął do konfiguracji jednak dane z dokumentu, który otrzymał – jak się okazało, dane produkcyjne. Uruchomienie testów jednostkowych aplikacji wyczyściło bazę, którą podał w konfiguracji – a która okazała się być produkcyjną.

Prawdziwy problem leży jednak po stronie firmy. Dane do produkcyjnej bazy danych nie powinny być dostępne dla programistów. Konto użyte do zrobienia backupu produkcyjnej bazy nie powinno mieć prawa zapisu do bazy. Po takiej akcji CTO zdecydowanie nie powinien winić o to programisty. Oh boy, długo mozna wymieniać.

Choose your licence, Luke!

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!