Open Source Initiative Board Meeting in Chicago

I’m celebrating the end of my portion of my trial by … spending all weekend in meetings, specifically the OSI’s annual face-to-face board meeting, which we’re holding this year in Chicago. It’s been a very productive meeting so far, with lots of good discussion about both our vision and our plan for attacking the future. The organization still has a long way to go but there is a lot of potential here.

Syndicated 2012-05-19 21:36:01 from Luis Villa » Blog Posts

Joining the Open Source Initiative board of directors

In the past, I’ve been known to say that skeptical things about the Open Source Initiative’s role in the open source world – usually arguing that OSI was doing the basics (license approval, open source definition) respectably, but also had a lot of potential that wasn’t being taken advantage of. I’m excited to announce that I’m now putting my money where my mouth is, and joining the OSI board of directors.

“Hello, My Name is Open Source” by opensourceway, used under CC-BY-SA license

I’ll write more about my goals for OSI (and for my participation in it) in the coming months, once I’ve gotten a chance to actually meet with the rest of the board and better understand the projects that are already underway. But right now I think it’s very important to note how I became a member of the board, because I think it says something important about where OSI is going, and about why I agreed to invest my time and energy.

Specifically, at FOSDEM, OSI announced that it was beginning to shift in part to an affiliate model, where open source organizations like Mozilla, KDE, and others would have input into OSI’s processes and decisionmaking.¹ One of the first tangible outcomes of that process was to ask affiliate orgs to nominate board members. The result: Mozilla nominated me, and Eclipse nominated fellow new board member Mike Milinkovich. Because of this, our election is less about us,² and more about taking very concrete steps towards an OSI with deeper ties to the broader open source community. And that, I think, reflects what OSI has not always been, but could be – a place where the best of open source can talk and work together to move common interests forward.

1. Ask me how your organization can join!
2. Though obviously I expect we’ll be great :)

Syndicated 2012-03-19 23:09:55 from Luis Villa » Blog Posts

On the Importance of Per-File License Information

After the release of MPL 2, the first request for MPL 2.1 came from someone who didn’t want to put copyright headers in individual files. The issue has recently reared its head in Apache as well, and I recently was asked related questions by a GPL user as well.

The main reasons given for not using per-file headers are two-fold:

1. They’re awkward in short files. Many programming frameworks these days (most notably rails) are encouraging creation of many short files, so this is becoming a bigger problem than it was when per-file headers were first created.
2. They’re not considered very relevant in languages or frameworks that are library-centric, especially those with package managers that are heavily used (like ruby’s gems). Again, many modern language frameworks include tooling that encourages this approach, so some developers are thinking “why can’t I just express the license once per library?”

The case for per-file copyright headers is put well, and succinctly, by Larry Rosen:

“[O]ur goal is to pass on any important IP information that might be useful … in the place(s) [downstream licensees] are most likely to find it.”

Larry’s comment makes two assumptions that I want to flesh out and support.

First, Larry assumes that the place where people are “most likely to find” licensing information is in per-file headers. It is true that in the best case scenario in many modern languages/frameworks, library-level is a great place to put licenses – in normal use, they’ll get seen and understood. But lots of coding in the wild is not “normal use.” I review a lot of different codebases these days, and files get separated from their parent projects and directories all the time. And then you have to use fairly complex (and often expensive) tools to do what should be a simple task- figure out what the license is. So, yes, modern frameworks should in theory reduce the need for per-file licensing information – but in practice, that is often not the case.

Second, Larry assumes that you actually want people to use your code. Lots of publishers of open source code seem surprisingly unconcerned by this, unfortunately. The functional, practical benefits of open source all start with someone else reusing your code, so if you’re publishing open source code at all, you should be concerned about making it easy for people to use the code you publish. Again, putting licensing information in each file can help make this easier, by making it easier for people to figure out their rights and responsibilities. (This is particularly true if you want commercial uptake, since so many commercial users of open source are getting more conservative about using source code that is not properly labeled and licensed.)((Larry also perhaps assumes you want people to respect your license when using your code; that is a surprisingly complex topic that I will try to address some other day.))

So, yes: if you want people to find your licensing information, and  to use your code, per-file headers are the way to go. They may not be ideal but they really are worth the effort.

Syndicated 2012-03-17 18:43:00 from Luis Villa » Blog Posts

The license term smorgasbord: copyleft, share-alike, reciprocal, viral, or hereditary?

I microblogged (diaspora, identica, twitter) the following statement a few weeks ago:

First new year’s resolution, 10 days late: I will use ‘hereditary license’ any time I am tempted to say ‘viral license.’

Surprisingly, this generated quite a few responses (on identica and elsewhere)- some people liked it, but many people had their own alternative to propose. So here are some longer-form thoughts.

There are four primary options that I am aware of when trying to find a one-word term for open source licenses that in some way compel distributors to also distribute code- i.e., the licenses called “copyleft” by those of us who have spent too much time with this stuff. The terms:

• Copyleft: This is the common name when speaking to other people experienced in open source, so it’s obviously the first choice when you know your audience has at least some experience in open source. But to an audience not already involved in open source (the only time I’m ever even vaguely “tempted to say viral”), the phrase is completely non-obvious. It has zero evident meaning. In fact, it can actively confuse: it could mean the reverse of copyright, which to most people probably means “no license” or anti-copyright altogether. So it’s really not a good word to use for audiences who aren’t familiar with open source- which is to say, most audiences.
• Viral: This is another old standby. Traditionally, the objection to this term has been that it is perjorative: no one likes viruses, so ‘viral’ is often seen as (and sometimes is) a deliberate attempt to frame copyleft licenses as inherently bad. That objection is certainly accurate, but I think there is another problem with this word: it implies that, like a virus, copyleft can spread to someone without their active involvement; you can “catch” it from the digital equivalent of being in the same room with someone, or not washing your hands. This isn’t the case – there must be a strong relationship between the copylefted code and the other code that might be required to be shared. This, to me, is where “viral” really fails to communicate. It makes people think that a copyleft is something that might “happen to them” instead of it being something that they have to be actively involved with.
• Share-alike (or the related word “reciprocal”): Oddly, neither of these is used much outside of the Creative Commons world. Neither of these are bad terms: they are reasonably value-neutral, and they both imply that there must be an actively chosen relationship between the parties, which I think is important. But to me they don’t capture the why of the relationship; it makes it sound like there might be a choice in the matter, or something you do because you’re a nice guy.
• Hereditary: Richard Fontana traced this back to at least 2004, so it isn’t new, but without doubt this is the least used of the various terms I’m discussing here. At least for the moment, though, and for general audiences, I’m leaning towards thinking it is the best option. First, it implies that there has to be a real, derivative relationship between the two codebases; it can’t just happen at random (like viral implies). Second, it also implies that once the relationship exists, further licensing isn’t a choice- you must pass it on to the next folks who “inherit” from you. (Share-alike/reciprocal might imply that you do this because you’re a nice guy, which isn’t the case, or that you do it back to the original sharer- which also isn’t necessarily the case.) The analogy obviously isn’t perfect, most notably because a mere redistributor who hasn’t created a derivative work that “inherits” from the parent work is still bound by the license. But I think on balance that it has the fewest tradeoffs.

So there you go, for the dozen people who asked, and the hundreds, nay billions more who don’t care :)

Syndicated 2012-02-03 02:14:21 from Luis Villa » Blog Posts

Nominated for OpenSource.com People’s Choice Award

Based on my series of MPL posts for opensource.com, I’ve been nominated for a “people’s choice award” as a top contributor to opensource.com. It’s a nice little honor. That said, there are lots of folks on the list of nominees who have written and thought far more than I have this year- so you should go check out the list and vote for one of them instead :)

Syndicated 2012-01-24 20:42:15 from Luis Villa » Blog Posts