Tag: Open Source

Creative Commons beta tests new search

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.

 

Maintainers Don’t Scale

Daniel Vetter, one of the Linux kernel maintainers, shares some thoughts on why maintainers don’t scale, what it takes to do the job, what has changed recently and what needs to change in the future.

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.

Open Source Lawyer as a Career

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 first one is “The Tech Contracts Handbook: Cloud Computing Agreements, Software Licenses, and Other IT Contracts for Lawyers and Businesspeople“.

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
  • Indemnities
  • Disaster recovery (DR)
  • Non-competes
  • Limitations of liability
  • Clickwraps
  • 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).

GPL defense issues

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
really antsy.

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.

EPEL : the effort behind the scenes

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!