Opensource and Go. What license?
87% of Go code in GitHub is licensed under a permissive license such as MIT, Apache, and BSD 3-clause. I see this as a very welcome scenario. I believe that when source code is publicly available on the Internet, it should be distributed free of legal consequences.
The Encyclopedia of things considered harmful has a great collection of content regarding intellectual property, where you can learn how this state-sponsored monopoly was created. There, you can learn how evil and stupid it can be if you are like me and believe in a free society and free markets.
tl;dr: Everyone understands public domain concepts, MIT, BSD, or ISC in 60 seconds or less. Pick one such license and be happy.
Permissive vs. copyleft licenses
There are two common types of opensource licenses categories: permissive and copyleft.
Copyleft licenses have restrictions against at least one of the following: use, modification, or redistribution. It carries a legal burden affecting companies and technical people alike. Permissive licenses grant their users these rights and vastly simplify legal compliance.
Reasons to use a permissive license for your Go code
Go is a statically-linked programming language
When you write a program, you almost always use different packages. Be it part of standard library, libraries developed by the community or by your team.
Go was designed to work with packages put together with your application code at compilation time on a stand-alone binary. In other words, Go uses statically linking.
What is linking? Linking is the process of taking one or more object files generated by a compiler and combining them into a single object or package.
Static linking makes your programs larger but more portable. The dependencies are self-contained, and this avoids sorts of linking problems found on Linux distributions and programs were dynamic linking is more common (Shared Libraries).
One benefit of using dynamic linking is reducing memory footprint. What is interesting for your old computer with 512MB of RAM. Not so much if we are talking about your newer computer with 4+ GB of RAM.
You can read Anatomy of Linux dynamic libraries by M. Tim Jones to understand more about dynamic libraries.
Applications for macOS typically uses a static linking approach too.
They use packages that — despite loading just like a regular executable on most platforms — are actually bundles: directories with a defined structure and the .app extension. This was inherited from the NeXTSTEP days.
What about linking binary packages in Go?
Go supports limited linking to packages without the source code. Recently, support for binary-only packages was deprecated. Your next best bet is using plugins. A fresh concept and only supported on Linux and macOS.
GPL linking issue
Source code licensed under a GPL license can only be linked by other software that uses GPL or, for GPLv3, also compatible licenses. A GPL linking exception is commonly found on many GPL licensed programs.
Lesser GPL (LGPL) linking issue
The GPL license is so limited that a Lesser GPL (LGPL) exists to try to resolve the linking issue. However, for the Go programming language the LGPL license is equivalent to GPL because of this clause:
“If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.”
Source: LGPL 2.1
Affero GPL (AGPL) nightmare
The worse license ever. It is GPL with more restrictions. It prohibits network traffic on modified source code if you don’t share it under the very same agreements.
No wonder there is a policy against using AGPL'ed software at Google.
License proliferation risk
Go is known by its high-quality standard libraries and “extra-official” libraries. Compared to other ecosystems, though, it has a lean number of similar libraries on any given field.
One interesting fact is that many packages on its standard library were born outside of it. The context package is a great example. It went from being a "de facto" to an official standard library package thanks to solving an important problem for the community.
Another good example is the official experimental dependency management tool dep, which was created by the collaboration of competing dependency management tool teams to create an official tool. Thanks to this goal, go mod was born.
License proliferation would hurt code reuse between different projects by taking away the focus on engineering and making the ecosystem weaker.
Adding dependency vs. copying code
“A little copying is better than a little dependency.”
~ Rob Pike
One of Go’s Proverbs. It means that sometimes copying a little bit of code is better than adding a small dependency. This is a widespread practice in the Go community.
No-frills permissive licensing means that it is pretty straight-forward to decide to use a piece of code useful to solve a problem, give due credit, and move on, instead of wasting time with legal vetting, and risks.
Laissez-faire attitude towards reusing code
I’m unsure why, but maybe because Go is a very concise and orthogonal language, in my experience a lot of code ends up being reused.
Compare: Go has 25 reserved words, C has 32, and Java has 50.
And I’m not talking about possible code reuse inside a single project. But over several projects, by different people. Facilitating both the creation of entirely new projects or just snippets of code.
Collaboration is good
It’s common for Go developers to help each other answering questions on StackOverflow, Gophers’ slack or on freenode’s #go-nuts channel. Sometimes this might involve pointing to existing code on other projects. It always helps that most projects use friendly permissive opensource licenses.
Don’t fear someone will take your code, run away, and create a 1M dollar company behind your back and give you nothing in return. Ideas are not scarce. They are not exclusionary either.
However, if you do a scientific analysis and believe you might lose by sharing your code or binary, know your premises might be wrong. Hostile forks and copycats are the exceptions, not the norm. Don’t commit the mistake of worrying too early, especially if you have a competitive product.
If you genuinely believe you are not, you might consider making your software available as SaaS (Software as a Service) — if it fits your problem domain — to escape this risk altogether.
Developer morale and outreach
Letting other people see your code you might attract welcome contributions (though sometimes it can be a burden) or partnerships.
For a company, it might mean attracting partners and potential workers for its projects. One great example is how Google opened the source of Kubernetes — a solution for orchestrating microservices with open standards and protocols, helping it conquer a leading position on the cloud market.
Compliance
Some licenses have language that suggests you shall give credit somewhere on your software.
vendorlicenses is a tool I wrote that checks and concatenate licenses found on the vendor directory of your program to do that. It produces a list of dependencies used to build your software. This list is usually found on a legal submenu hidden somewhere on software, consumer devices, such as cellphones, videogames, or car media players.
If you need legal protection, you might want also to use FOSSA for vetting.
Final thoughts
To learn more about my position on this matter, I recommend the book Do Business WITHOUT Intellectual Property by patent attorney Stephan Kinsella.
If you disagree with my opinion and are not an attorney or lawyer enriched by the schemes of patent trolling or copyright persecution, I believe that at least you should be aware of the high cost of suing for copyright infringements.
I hope you enjoyed my blog post.
