Older blog entries for louie (starting at number 680)

Pushing back against licensing and the permission culture

tl;dr: the open license ecosystem assumes that sharing can’t (or even shouldn’t) happen without explicit permission in the form of licenses. What if “post open source” is an implicit critique of that assumption – saying, in essence, “I reject the permission culture”? If so, license authors might want to consider creating options that enable people to express that opinion.

A few months back, James Governor said:

younger devs today are about POSS – Post open source software. fuck the license and governance, just commit to github.

— James Governor (@monkchips) September 17, 2012

While the actual extent of “POSS” is debatable, there is definitely an increase in the amount of unlicensed code out there. This post suggests 20+% of the most-watched github projects are unlicensed. The pushback against licensing isn’t specific to software, either – at least some sharing musicians are deliberately spurning Creative Commons (via Lucas) and Nina Paley has been obliquely making the same point about the licensing of her art as well.

A few months back, I pointed out that the lack of licensing led to confusion and so was great for lawyers. That post was accurate, but slightly glib. Here, I want to grapple more seriously with the rejection of licensing, and provoke the licensing community to think about what that means.

A dab of history and context

In the US, prior to the 1976 Copyright Act, you had to take affirmative steps to get a protectable copyright. In other words, you could publish something and expect others to be able to legally reuse it, without slapping a license on it first.

Since the 1976 Act, you get copyright simply by creating the work in question. That means every blog post and every github commit is copyrighted. This restrictive default, combined with the weakness of fair use, leads to the “permission culture” – the pernicious assumption that you must always ask permission before doing anything with anyone’s work, because nothing is ever simply shared or legally usable. (This assumption is incorrect, but the cost of acting that way can be high if you make a mistake.)

Permission, by Nina Paley.
Permission, by Nina Paley.

“POSS” might be more than just bad hygiene

It is easy to assume that the pushback against licenses (“post-open source”) is because licensing is confusing/time-consuming and people are lazy/busy. While I’m sure these are the primary reasons, I think that, for some people, the pushback against licenses often reflects a belief that “no copyright should mean no permission needed”. In other words, those people choose not to use a license because, on some level, they reject the permission culture and want to go back to the pre-1976 defaults. In this case, publishing without a license is in some way a political statement  – “not every use should need permission”.1

Fixing(?) the politics of our licenses

If some “no license” sharing is a quiet rejection of the permission culture, the lawyer’s solution (make everyone use a license, for their own good!) starts to look bad. This is because once an author has used a standard license, their immediate interests are protected – but the political content of not choosing a license is lost. Or to put it another way: if license authors get their wish, and everyone uses a license for all content, then, to the casual observer, it looks like everyone accepts the permission culture. This could make it harder to change that culture – to change the defaults – in the long run.

So how might we preserve the content of the political speech against the permission culture, while also allowing for use in that same, actually-existing permission culture? Or to put it more concisely:

What would a “license” that actively rejects the permission culture look like?

A couple of off-the-wall options:

  • Permissive+political preamble license: The WTFPL license (“Do WTF you want“) has been floating around for ages, and using it makes the point that (1) you want people to use your code and (2) you’re irritated that they even have to ask. Adding a brief “I hate that I have to do this” preamble to a permissive license like CC-0 might serve a similar purpose, while providing more legal certainty than WTFPL. (And of course such a preamble could also be used with a strong copyleft, like copyleft-next.)
  • Fair Use supplement: Fair use is the traditional safety valve for copyright, but it is hard to know if a particular use is “fair.” So a “license” could be written that, instead of formally licensing under specific terms, instead aims to provide more certainty about fair use. Some ways this could be done would include broadly defining the fair use categories, explicitly accepting transformative use as a factor in the fair use analysis, or asking courts to interpret ambiguity in favor of the recipient instead of the author. It is also possible to imagine this as a supplement to the existing fair use clauses in modern licenses (CC-BY 3.0 Sec. 2, GPL v3 Sec. 2, MPL 2 Sec 2.6), laying out a strong vision of fair use to help guide and protect anyone relying on those clauses.
  • “What People Actually Think Copyright Is” license: most Americans2 think that personal use of copyrighted materials is legal under modern copyright law. So a license that focused on personal use might work better than the more nebulous “non-commercial”. As a bonus, since commercial interests will clearly be unable to use the content, getting it “right for lawyers” may be less of a concern.

Careful readers will note that the last two options are unlikely to be OSI-open or FSF-free. For the purposes of this exercise, that’s OK- OSI, FSF, and CC’s iron-clad assumption that licensing is good is what I’d like to provoke people to think about here.3

Conclusion, and provocation

I don’t offer these license ideas as a comprehensive survey of what an anti-permission-culture license might look like, or even a good survey. Instead, take them as a provocation: are we – particularly authors and evaluators of open licenses – part of the problem of the permission culture? Are we actually responding to the people who use our licenses, if one of their desires is to push back against the need to license? Can we be more creative about expressing distaste for the permission culture, without gumming up the works of sharing too much? I think that, if we think critically, we can, and perhaps we should.

  1. Another motive, that I won’t go into here but which also deserves serious discussion for license authors, is simply that the values encapsulated in our licenses are taken for granted by younger developers who have always had a plentiful, healthy free-as-in-beer code commons. Both the permissive and copyleft communities would do well to argue the case for their licenses (not just their overall philosophies) better than they currently do.
  2. per Jessica Littman, Digital Copyright, p. 117
  3. If it wasn’t already obvious, this post is obviously not made with my OSI hat on – OSI continues to firmly endorse the Open Source Definition.

Syndicated 2013-01-28 03:00:20 from Luis Villa » Blog

So, iPhone friends: Anyone using Simple? Like it?…

So, iPhone friends: Anyone using Simple? Like it? Useful? Worth signing up for (now that they have Android)?

Syndicated 2013-01-15 18:08:51 from Luis Villa » Blog

Important, excellent long read from @matthewstolle…

Important, excellent long read from @matthewstoller on @aaronsw ‘s broader approach to politics. Read the whole thing. nakedcapitalism.com/2013/01/aaron-…

Syndicated 2013-01-14 15:07:21 from Luis Villa » Blog

Apologies for any spamming

Apologies to any planets/feeds I’m spamming with old tweet-junk right now; I’m trying to archive some tweets into WP and that may lead to some noise temporarily!

Syndicated 2013-01-14 03:45:19 from Luis Villa » Blog

Great article by @pchestek on “belt and suspenders…

Great article by @pchestek on “belt and suspenders” assignment of IP: feedproxy.google.com/~r/PropertyInt…

Syndicated 2013-01-10 14:48:38 from Luis Villa » Blog

A revised OSI “Open Source Licenses” page

When someone new to open source does a web search for “open source licenses”, the first page that comes up1 is opensource.org/licenses – making it one of the most important resources for newcomers to open source.2

Despite that, until today, all that a newbie would get when going to that page was two links: one to the list of approved licenses alphabetically, and another by category. This is obviously not ideal – it provides the newcomer with information useful only to an expert, so they lose; and OSI misses an opportunity to educate and inform, so we lose.

Because of this, in the middle of last year I sent an email to license-discuss proposing a revision to the page, and followed up several times in the second half of the year. Yesterday, I took the revision live.

Don't do a nano without them by mpclemens, used under CC-BY 2.0.
Don’t do a nano without them by mpclemens, used under CC-BY 2.0.

Here is what the revision does, in a nutshell:

  • gives context: what is an open source license? what does OSI-approved mean? These give a newcomer to the list a fighting chance of figuring out what the lists mean.
  • provides a less-overwhelming list of licenses: using the “popular, widely used, or have strong communities” list created by the 2006 Proliferation Report, it gives people pointers to several useful licenses immediately, while still providing access to the full lists.
  • works with OSI’s other resources: The new page links to OSI’s excellent FAQ and the annotated Open Source Definition, among other things. Again, these provide context, and help the page serve as a gateway for others.
  • is progress: OSI can be, and often should be, a very change-averse organization. But it is nice to score a small win here and there- I hope this will be the first of many while I chair the license committee.

And what it doesn’t do:

  • change the world: I’m blogging about this because it’s significant. But I also want to be clear that it is only a small win, and hopefully one that in 2-3 years OSI will look back on and have a good chuckle about.
  • change, update or revise the license categories: The original license proliferation committee license categories, from 2006, have been useful to many people, and were instrumental in slowing the pace of license proliferation. So they make sense to use as the (relatively neutral) basis for the list that is now prominent on /licenses/. But they’re showing their age- notably by including CDDL in “popular/widely used” but in other ways as well (primarily, by not categorizing a variety of new licenses). OSI’s licensing committee (aka the license-discuss list, with input from others) will be gradually investigating how to address this over the course of the next year or so. This process has already started, somewhat, with my calls for quantitative criteria for license analysis. I intend to continue to push the list (including hopefully new members!) to think through the issue and its implications.

If you’re interested in helping out with future changes, please join the list.

  1. other than an ad for opensource.com, interestingly
  2. Interesting research question/bleg: for a reasonably comprehensive set of important “open source + foo” terms, like collaboration, licensing, etc., where do search results point at? How many go to opensource.org? .com? other sites? Is there a tool that will do this sort of analysis automatically?

Syndicated 2013-01-03 16:30:26 from Luis Villa » Blog

Licensing confusion is great! (for lawyers)

I want to heartily unendorse Simon Phipps’ Infoworld article about Github and licensing. Simon’s article makes it sound like no one benefits from sloppy licensing practices, and that is simply not true. Specifically, lawyers benefit! I regularly get calls from clients saying “I have no idea if I’m allowed to use <project X>, because it is on github but doesn’t have a license.” When that happens, instead of money going to developers where it could actually build something productive, instead, I get to spend my time and the client’s money fixing a problem that the original author could have easily avoided by slapping an Apache license on the thing in the first place – or that github could have avoided by adding default terms.

So, support your local open source lawyer today – publish source code without a license!1

  1. Tongue firmly in cheek, in case that isn’t obvious. Seriously, lawyers are the only ones who benefit from this situation, except for that handful of seconds it took you to “git add LICENSE”. Always license your code, kids!

Syndicated 2012-12-03 17:13:47 from Luis Villa » Blog

Showrunner and Show Bible? Or Cult?

I don’t currently do much heavily collaborative writing, but I’m still very interested in the process of creating very collaborative works. So one of the many stimulating discussions at Monktoberfest was a presentation by two awesome O’Reilly staffers about the future (and past) of authorship. Needless to say, collaborative authoring was a major theme. What particularly jumped out at me in the talk and the discussion afterwards was a nagging fear that any text authored by multiple people would necessarily lack the coherence and vision of the best single-author writing.

I’ve often been very sympathetic to this concern. Watching groups of people get together and try to collaboratively create work is often painful. Those groups that have done best, in my experience, are often those with some sort of objective standard for the work they’re creating. In software, that’s usually “it compiles,” followed (in the best case) by “it passes all the tests.” Where there aren’t objective standards all team members can work with – as is often the case with UI  – the process tends to fall apart. Where there are really detailed objective standards that every contribution can be measured against – HTTP, HTML – open source is often not just competitive, but dominant.

On the flip side, you get no points for thinking of the canonical example of a single designer’s vision guiding the development of software. But Apple is an example that proves the rule – software UIs that are developed without reference to objective standards of good/bad are usually either bad, or run by a not-very-benevolent dictator who has spent decades refining his vision of authorship.

Wikipedia is another very large exception to the “many cooks” argument. It is an exception because most written projects can’t possibly have a rule of thumb so straightforward and yet effective as “neutral point of view,” because most written projects aren’t factual, dry or broken-up-into-small-chunks. In other words, most written projects aren’t encyclopedias and so can’t be written “by rule.”

Or at least that’s what I was thinking during the talk. In response to this, someone commented during the post-talk Q&A1 that essentially all TV shows are collaboratively written, and yet manage to be coherent. In fact, in our new golden age of TV drama they’re often more than coherent- they’re quite good, despite extremely complex plots sprawling over several years of effort. This has stuck in my head ever since because it goes against all my hard-learned instincts.

I really don’t know what the trick is, since I’m not a TV writer. I suspect that in most cases the showrunner does it by (1) having a very clear vision of where the show is going (often not the case in software) and (2) clearly articulating and communicating that vision – i.e. having a good show bible and sticking to it.

If you’re not looking carefully, this looks a lot like what Aaron has rightly called a cult of personality. But I think, after being reminded about showrunners and show bibles, it is important to distinguish the two. It is a fine line, but there is a real different between what Aaron is concerned about and skilled leadership. Maybe a good test is to ask that leader: where is your show bible? What can I read to understand the vision, and help flesh it out like the writer of an episode? If the answer is “follow whatever I’m thinking about this month,” or “I’m too busy leading to write it down”, then you’ve got problems. But if your leadership can explain, don’t throw the baby out with the bathwater- that’s a person who has thought seriously about what they’re doing and how you can help them build something bigger and better than you could each do alone, not a cult leader.

  1. if you’re this person, please drop me a note and I’ll credit you!

Syndicated 2012-11-14 16:07:55 from Luis Villa » Blog Posts

Thanking Contributors by Printing the MPL

As part of a general drive to get rid of stuff, I’ve recently become increasingly willing to part with my old books. This has been a painful process – books have many happy memories for me – but I think also a good and focusing one. As part of my emotional reaction to this, I’ve become increasingly interested in making beautiful, printed texts – things that stand up better to the test of time than the paperbacks I’ve been thinning out.

In 2010, as part of this process, I bought Typography for Lawyers, and incorporated some of what I learned from that into the HTML version of MPL 2.0. In 2011, as I was putting the finishing touches on the final draft of the MPL,  I attended the holiday fair at the San Francisco Center for the Book (neat Flickr stream), and ran across some work from Painted Tongue Press- beautiful broadside printings of poetry and wedding vows.

This gave me the idea to thank the most involved contributors to the MPL with a hand-made, printed copy of the text of the license.

The wonderful Kim Vanderheiden, of Painted Tongue, worked with me over the course of several months to plan this process, and then she and her team put them together. First, we designed the layout, not just of the text, but of the relatively unusual accordion-fold binding, which allowed the final product to be displayed like an A-Frame or by hanging the entire (very long!) thing from a wall. Then we picked paper for the text, and cloth and ribbon for the bindings (the ribbon symbolising both the fact that these are gifts and traditional bindings for legal documents). Kim’s team then hand printed them on their presses, and Kim used watercolors to paint the colored highlights (including the yellow highlighting that replaces the ALL CAPS text). Finally, they were bound.

The end result has been fifteen copies of beautiful, tangible, printed words, which I am now in the slow process of distributing to various contributors. I hope that this token of the maintainers’ appreciation for their assistance (in a variety of ways) is appreciated.

The front cover of the MPL printing, showing the ribbon and bow. The dino head, hand-colored. Hand-colored replacement for ALL CAPS. The thank you page.

The thanks and colophon is as follows:

Thank You!

This revision of the MPL would not have happened without your  help. Please accept this hand-crafted printing of the license as a token of our appreciation, and a reflection of the effort and care you put into your contributions to the license.

The MPL Module Owners

Mitchell Baker
Harvey Anderson
Gervase Markham
Heather Meeker
Luis Villa

-o-

Colophon

The type was set in Equity by Matthew Butterick (typo.la/equity – used with permission of the typographer) and Droid Sans Mono by Google (droidfonts.com – used under the Apache 2.0 license). The book is printed on Somerset Velvet Radiant White and covered in Duo Cloth Birch.

Design, printing, binding, and painting were done with care by the excellent team at Painted Tongue Press, Oakland, California (paintedtonguepress.com).

This edition of MPL 2.0 was printed in August 2012 to celebrate the publication of, and thank contributors to, MPL 2.0. You are holding copy # __
of 15.

Syndicated 2012-11-13 06:03:27 from Luis Villa » Blog Posts

AGPL is usually about free riding, not fragmentation or adoption

When I was at Monktoberfest, our esteemed host reminded me that I’d disagreed with his article “AGPL: Solution In Search of a Problem”, and nudged me to elaborate on the point. Here goes nothing. TL;DR: for most developers, AGPL is really about preventing free riding, not fragmentation – so as long as there is concern about free riding people will use AGPL.

Stephen makes a few key points in his article (mistakes in paraphrasing mine):

  1. AGPL’s alleged benefit (the “problem that doesn’t exist”) is the prevention of fragmentation.
  2. Permissive licenses are on the rise, so using a super-strong copyleft is counter-productive when you’re looking to attract developers.
  3. By being so aggressive, it courts FUD about all open source licenses, which could be counter-productive to open source generally.

Let me take these in order.

Urban Fragments, by APM Alex under CC-BY 2.0

Issue #1 is based on a misapprehension: I don’t think it’s correct to think of the purpose of any copyleft (Affero or otherwise) as preventing fragmentation. GPL has never prevented fragmentation – there have been forks of many GPL projects (and complaints about same) for about as long as GPL has been around. (*cough*emacs*cough*)

Critically for many developers, what GPL does attempt to prevent is free riding – taking a benefit without contributing back. GPL means any valuable improvements in forks (whether or not incompatible) are available to integrate back under the same license terms. This means you can’t “cheat” the primary developers by building your business around proprietary forks of “their” work – they can always reincorporate the valuable bits if they want to.

The frequent use of AGPL in commercial dual-licenses also suggests that free riding is the problem being attacked by strong copylefts, not fragmentation. The logic is simple: AGPL means users usually pay some cost (i.e., not free ride) to participate: either by buying a commercial license, or by sharing code. In contrast, if the goal was to limit fragmentation, the license would say something like “your patches have to be accepted back into the core, or else you have to write a check”, or even better “you have to pass a compatibility test, or else you have to write a check.”

It is important to note that “cheat” is in quotes above. In many cases, people have realized that maintaining proprietary forks isn’t actually cheating the primary developers. For example, in many cases, we’ve realized that forking primarily cheats the forkers. For example, many users of the Linux kernel have learned the hard way that running an old fork + a small proprietary module leads to very high maintenance costs. In other cases, the permissive license actually helps fund the primary developers by enabling an open-core model (even if those aren’t trendy at the moment). In yet other cases, the primary author is making their money from other tools or services and so doesn’t care if anyone free-rides on their open source components. 37 Signals and Rails are probably the poster child for this. And of course, much of the industry has simply gotten more mature and less possessive about their software – realizing that whether or not they are “cheated” is usually a silly concern.

This leads to my response to issue #2: in my opinion, the recent increase in permissive licenses is driven as much by the decreasing concern about “cheating” developers (aka free riding) as it is by increased interest in adoption. In that light, the use case for AGPL is straightforward: AGPL makes sense if you’ve got a good reason to be concerned about free riding (say, if your revenue is directly tied to the tool you’re choosing a license for). This is a decreasing number of people, for the reasons described above, but it’s still far from zero. For those folks, increasing adoption may not actually be useful – it’s a case of “we lose money on every sale, but we’ll make it up on volume”.

On Issue #3 (increased FUD risk): this certainly seems like a possibility, but in my practice, I’ve seen only a single instance of confusion caused by AGPL spilling onto other licenses, and it was quick and easy to clear up. There is certainly plenty of worry about AGPL, but the worriers are quite clear that this stems from requirements other licenses don’t share. Maybe there will be more confusion if/when someone drafts another Affero-style license, but it doesn’t appear to me to currently be an issue. (By way of contrast, the confusion about the various patent clauses, and who licenses what to whom when, is a recurring theme of discussion with any company that is both filing patents and doing open source.)

Finally it’s important to note that both my post and Steve’s are about the costs, benefits, and freedoms accorded to developers. As I’ve mentioned before, when thinking about what “problem” is being solved by a license, it’s always important to remember that for some people (particularly the authors of the AGPL) the analysis begins and ends with problems for users. A full analysis of that issue has to wait for another day (it may be reminiscent of bike helmets) but suffice to say that neither of us are attempting it here, and we should always be cognizant of that.

Syndicated 2012-10-09 15:00:04 from Luis Villa » Blog Posts

671 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!