GitHub added Open Source license descriptions. This is a tiny, but very useful feature, especially for those people who are not very well versed in the differences between GPL, MIT, BSD, and other licenses. I wish there was a way to have something like this proprietary applications. Maybe then people would pay attention to the end user license agreements (EULAs).
GitHub blog is “Announcing Open Source Guides“:
we’re launching the Open Source Guides, a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to open source.
Open Source Guides are a series of short, approachable guides to help you participate more effectively in open source, whether it’s:
- Finding users for your project
- Making your first contribution
- Managing large open source communities
- Improving the workflow of your project
These guides aim to reflect the voice of the community and their years of wisdom and practice. We’ve focused on the topics we’ve heard about most, and curated stories from open source contributors across the web.
I think it’s a great idea and I really like the execution too. Most of what I know about Open Source comes from years of participation, and from reading old books, manuals and licenses – not something that is easy to share with people who are just getting their feet wet.
GitHub’s Open Source Guides are very simple, concise and specific. And they cover a variety of subjects, not just the legal or technical side of things, but also communications, support, marketing, etc.
Creative Commons is beta testing a new search implementation. It helps with finding creative work (mostly images for now) that one can use commercially, modify, adapt, and build upon. For now, it brings the results from a few different sources that you’d have to search separately before – 500px, Flickr, Metropolitan Museum of Art, New York Public Library, and Rijksmuseum.
I’m sure once the functionality and performance are stabilized, more resources and types of creatives will be added. After all, Creative Commons works with quite a few platforms.
Oh, and if you’ve spent the last few years in a cave and don’t know what Creative Commons is all about, here are a couple of links for you:
Via WordPress Tavern.
This reminded me of this infographic, which depicts a year (even though back in 2012 – probably much busier these days) for another kernel maintainer – Greg Kroah-Hartman. Note that the number of emails does not include the messages on the Linux kernel mailing list (LKML), which is in its own category of busy:
The Linux kernel mailing list (LKML) is the main electronic mailing list for Linux kernel development, where the majority of the announcements, discussions, debates, and flame wars over the kernel take place. Many other mailing lists exist to discuss the different subsystems and ports of the Linux kernel, but LKML is the principal communication channel among Linux kernel developers. It is a very high-volume list, usually receiving about 1,000 messages each day, most of which are kernel code patches.
OpenSource.com runs this article on “What to know before jumping into a career as an open source lawyer“. Whether or not you are planning to take that path, the article has a few interesting links and quotes.
Recently, at work, we’ve been trying to get a hold of a lawyer with Open Source experience. Just for the consultation or two. I wasn’t very optimistic about it, as I had a feeling those are rare beasts. My suspicion was confirmed to a degree. But this article reaffirms it even further:
Only a few dozen new grads a year are hired to do anything even vaguely involving open source. Only a few dozen lawyers in the entire world dedicate more than a quarter of their time to open source. Only a lucky handful, like those at Software Freedom Law Center (SFLC) and Software Freedom Conservancy (SFC), work primarily directly for communities and volunteer developers.
The article also links to a couple of books on the subject, which I’m pretty sure I’ll need to buy and read soon, unless we find somebody who is actually a lawyer and has done some work in Open Source space.
The Tech Contracts Handbook is a practical, user-friendly reference manual and training guide on cloud computing agreements, software licenses, and other IT contracts. It’s a clause-by-clause “how to” resource, covering the issues at stake and offering negotiation tips and sample contract language.
The Handbook is for both lawyers and businesspeople — including contract managers, procurement officers, in-house and outside counsel, salespeople, and anyone else responsible for getting IT deals done. Perhaps, most important, it uses clear, simple English, like a good contract.
Topics covered include:
- Software-as-a-service (SaaS) subscriptions
- Warranties and service level agreements (SLA’s)
- Data security and privacy
- Disaster recovery (DR)
- Limitations of liability
- Open source software
- Nondisclosure agreements (NDA’s) and confidentiality
- Technology escrow
- Copyright and other intellectual property (IP) licensing
- Internet and e-commerce contracts
- And much more …
The second one is “A Primer on Intellectual Property Licensing“.
A PRIMER ON INTELLECTUAL PROPERTY LICENSING (Second Edition) is a compact, practical guide to one of the most dynamic and popular areas of legal practice today-intellectual property licensing. Developed by an attorney in private practice who specializes in Silicon Valley technology licensing, this guide presents the basic rules of law you need to know for a licensing practice, along with helpful examples of contractual language, practice tips, and insights on custom and practice in the industry. This textbook is appropriate for a law school or business school seminar, or for practicing attorneys who wish to expand their practice into this exciting field. Individual chapters from this text are also available for seminars and CLE presentations (in electronic format).
A friend sent me a link to this email from Linus Torvalds to the Kernel Summit Discussion mailing list. The subject of the conversation is the General Public License (GPL) and whether or not it should be enforced in courts. Read the whole thing – it’s quite interesting. Here are a few snippets just to get you started:
Let’s be clear about this: lawsuits destroy. They don’t “protect”.
Lawsuits destroy community. They destroy trust. They would destroy all the goodwill we’ve built up over the years by being nice.
And then this:
Because lawsuits – and even threats of lawsuits – makes companies way less likely to see you as a good guy. Even when you’re threatening
somebody else, everybody else around the target starts getting really
I talked to an Oracle lawyer a few months ago, and told him their
lawsuit just makes Oracle look bad. The lawyer was dismissive, and
tried to explain how it’s silly how people take lawsuits personally,
and talked about how layers _understand_ that lawsuits aren’t
personal, and that they are still friends outside the court.
I’m sure a lawyer can “understand” how lawsuits aren’t actually
something personal at all, but lawyers really seem to be the *only*
people who “understand” that.
The fact is, lawsuits (and threats of lawsuits) do not make for
friends. You just look like a bully.
Catching up with recent news, I came across this blog post by Stephen John Smoogen in Fedora People, where he explains the reason for the recent disappearance of the Puppet package from the Extra Packages for Enterprise Linux (EPEL 6) repository:
This week various people using EPEL on RHEL and CentOS 6 have found that the puppet package is no longer provided by EPEL. The reason for this is due to the way EPEL packages are built and kept inside the repository. A package needs a sponsor so that we can hopefully get bug fixes and security updates to it. In the case of puppet this package is sponsored by the user kanarip. However, most packages aren’t whole pieces, they rely on other software.. in this case the package puppet relies on a lot of different ruby gems of which one of them was called ruby-shadow. This package was orphaned 30 weeks ago and while it did have other people watching it, none of them took over the package.
Last week a large cleanup was done to clean out orphaned packages from EPEL which removed ruby-shadow. Once that was removed, then all of the other packages depending on ruby-shadow were also removed. Today various people reinstalling systems found puppet wasn’t around and came onto #epel to ask.. which seems to have gotten the packages responsored and hopefully they will be back in the EPEL release in a day or so.
This problem has been happening a lot lately. I think it shows quite a few problems with how EPEL is set up and managed. For this, I take responsibility as I said I would try to clean it up after FOSDEM 2016 and it is still happening.
Unpleasant annoyance that shouldn’t have happened, right? Well, yes, maybe.
Software is a complex matter, whether you are designing, developing, testing, or distributing it. So things do go wrong sometimes. And that was something I wanted to focus on for a second.
Forget the actual designing, developing, testing and documenting the software. Forget all the infrastructure behind such a vital part of the Linux ecosystem as EPEL. Just think of this single issue for a moment. Once again:
A package needs a sponsor so that we can hopefully get bug fixes and security updates to it.
So what, I hear you say. Well, let’s take a closer look. EPEL provides packages for multiple versions of the distribution, hardware platforms and so on. Let’s just look at the EPEL 6 for x86_64 (to keep things simple). That looks like a lot of packages, doesn’t it?. How many? At the time of this writing, from a random mirror that I got:
wget -q -O - http://download.fedoraproject.org/pub/epel/6/x86_64/ | grep -c 'unknown.gif' 12129
Yup. That’s 12,129 packages! And each one of those has at least one developer behind it, to sponsor. Some of those amazing people obviously maintain more than one package. Some packages are maintained by multiple people. All of them are working hard behind the scenes for you and me to have an easy and stable access to a whole lot of software. Here is a quote from the FAQ which is smoked and marinated in all that effort:
Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description.
We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is ten years after release (currently) — a long time frame, and we know a lot can happen in ten years. Your participation is vital for the success of this project.
I don’t know about you, but for me, this is absolutely mind-blowing. So I just wanted to take this opportunity to say thank you to all the brilliant people behind the scenes, who are often invisible, yet indispensable for the continuous success of Open Source software in general, and Linux in particular.
You guys rock!
O’Reilly is giving away some programming ebooks for free. Not the greatest of selections, but might still come handy, as subjects vary from Java and Python to micro-services and software architecture. The books are available in ePub, Mobi, and PDF, but you’ll need to register / login to download them.
- Asynchronous I/O support, channels, JSON
- Partials, Lambdas and Closures
- New style testing
- Viminfo merged by timestamp
- GTK+ 3 support
- MS-Windows DirectX support
For a more complete list and details, have a look here.
The TL;DR summary: Vim provides a lot more power now to plugin developers, so we’ll be seeing a boost in both new functionality and old ways getting better.
Here is a mandatory Slashdot discussion with your usual Vim vs. Emacs flame.
P.S.: Emacs has recently released a major update too …
Here is a good Open Source story – “How Google Uses and Contributes to Open Source“, which goes into some detail and history of how Google is working with Open Source community.
I’ve seen this before:
“There are companies and people who just take the software and say, “I didn’t have to pay for it. I can do anything I want. The license file is a big blob of text. I’m not going to read that,” Merlin said.
And I’ve this (quite a few times actually):
Back in its early days, around 1998, Google was a small company. It was using open source just like any other small company. While Google was abiding by licences, they were not giving back much due to several reasons. “Some of it was just run fast and make sure that we have money next month to pay everyone’s salary,” said Merlin.
Having been involved in open sourcing companies’ projects new and old, this is what I firmly believe now is the best strategy:
Go open source from the beginning
Google changed that by writing a lot of things from the ground up as open source or to be open source ready. That was a good lesson that they learned, and that’s a problem many companies face when they want to open source their stuff but can’t because the code was not designed to be open source from the beginning.
This, I think, is an interesting approach too (if you are too small of a company to have research papers and algorithms, consider blog posts, tips and tweaks, case studies, and the like):
Even if Google can’t open source certain code, they found a way to bring that work to the public. “We wrote papers talking about the magic algorithm that we used. We can’t give you the code for the reason I just explained, but we’re giving you the way they work so you can rewrite them,” said Merlin. Google has published hundreds of such papers and people are using it to create projects based on those ideas.
This bit on Android is mind blowing:
Now virtually all of Google’s open source code is on GitHub, except for Android. “The Android distribution is so big and it gets released in big chunks. So, when it gets released, everyone wants to sync that,” Merlin said. “It’s so huge that if we put it on GitHub, it would completely kill GitHub. We use our own mirrors for that, to help out.”
A word of caution for the companies using Open Source software:
Companies have to be extremely careful when using open source. Different projects use different licenses, and you need to be in compliance with them.
Things become complicated when you have projects that you ship. In the case of open source, you need to list the projects that you use and their licenses. In the case of BSD and MIT, you need to list the name and the copyright of the person you got that project from.
You’ll probably need a set of tools to deal with issues like this. For PHP-based projects, composer is indispensable. You can run “composer licenses” command and instantly get information about the project’s license, as well as licenses for each and every dependency in use (thanks to this blog post).
There is a good section on Contributor License Agreements (CLAs). I am slightly familiar with the subject (I signed a few myself), but my experience is limited, especially from the company perspective. I found this part useful, for that distant time when I’ll need to set it up:
Google uses the Apache foundation ICLA, without modifying it or putting anything special in it. CLAs ensure that companies like Google “can re-license your code under a different open source (license) if we need to. Sometimes we need to merge with other projects and that’s what the CLA allows us to do,” said Merlin.
These are just bits and pieces which I found interesting. I wish more companies shared their practices and experiences – in particular those larger businesses, with years of history and a wide variety of challenges.