Older blog entries for louie (starting at number 698)

Designers and Creative Commons: Learning Through Wikipedia Redesigns

tl;dr: Wikipedia redesigns mostly ignore attribution of Wikipedia authors, and none approach the problem creatively. This probably says as much or more about Creative Commons as it does about the designers.

disclaimer-y thing: so far, this is for fun, not work; haven’t discussed it at the office and have no particular plans to. Yes, I have a weird idea of fun.

Refresh variant from interfacesketch.com.
A mild refresh from interfacesketch.com.

It is no longer surprising when a new day brings a new redesign of Wikipedia. After seeing one this weekend with no licensing information, I started going back through seventeen of them (most of the ones listed on-wiki) to see how (if at all) they dealt with licensing, attribution, and history. Here’s a summary of what I found.

Completely missing

Perhaps not surprisingly, many designers completely remove attribution (i.e., history) and licensing information in their designs. Seven of the seventeen redesigns I surveyed were in this camp. Some of them were in response to a particular, non-licensing-related challenge, so it may not be fair to lump them into this camp, but good designers still deal with real design constraints, and licensing is one of them.

History survives – sometimes

The history link is important, because it is how we honor the people who wrote the article, and comply with our attribution obligations. Five of the seventeen redesigns lacked any licensing information, but at least kept a history link.

Several of this group included some legal information, such as links to the privacy policy, or in one case, to the Wikimedia Foundation trademark page. This suggests that our current licensing information may be presented in a worse way than some of our other legal information, since it seems to be getting cut out even by designers who are tolerant of some of our other legalese?

Same old, same old

Four of the seventeen designs keep the same old legalese, though one fails to comply by making it impossible to get to the attribution (history) page. Nothing wrong with keeping the existing language, but it could reflect a sad conclusion that licensing information isn’t worth the attention of designers; or (more generously) that they don’t understand the meaning/utility of the language, so it just gets cargo-culted around. (Credit to Hamza Erdoglu , who was the only mockup designer who specifically went out of his way to show the page footer in one of his mockups.)

A winner, sort of!

Of the seventeen sites I looked at, exactly one did something different: Wikiwand. It is pretty minimal, but it is something. The one thing: as part of the redesign, it adds a big header/splash image to the page, and then adds a new credit specifically for the author of the header/splash image down at the bottom of the page with the standard licensing information. Arguably it isn’t that creative, just complying with their obligations from adding a new image, but it’s at least a sign that not everyone is asleep at the wheel.

Observations

This is surely not a large or representative sample, so all my observations from this exercise should be taken with a grain of salt. (They’re also speculative since I haven’t talked to the designers.) That said, some thoughts besides the ones above:

  • Virtually all of the designers who wrote about why they did the redesign mentioned our public-edit-nature as one of their motivators. Given that, I expected history to be more frequently/consistently addressed. Not clear whether this should be chalked up to designers not caring about attribution, or the attribution role of history being very unclear to anyone who isn’t an expect. I suspect the latter.
  • It was evident that some of these designers had spent a great deal of time thinking about the site, and yet were unaware of licensing/attribution. This suggests that people who spend less time with the site (i.e., 99.9% of readers) are going to be even more ignorant.
  • None of the designers felt attribution and licensing was even important enough to experiment on or mention in their writeups. As I said above, this is understandable but sort of sad, and I wonder how to change it.

Syndicated 2014-07-16 06:31:48 from Luis Villa » Blog

Democracy and Software Freedom

As part of a broader discussion of democracy as the basis for a just socio-economic system, Séverine Deneulin summarizes Robert Dahl’s Democracy, which says democracy requires five qualities:

First, democracy requires effective participation. Before a policy is adopted, all members must have equal and effective opportunities for making their views known to others as to what the policy should be.

Second, it is based on voting equality. When the moment arrives for the final policy decision to be made, every member should have an equal and effective opportunity to vote, and all votes should be counted as equal.

Third, it rests on ‘enlightened understanding’. Within reasonable limits, each member should have equal and effective opportunities for learning about alternative policies and their likely consequences.

Fourth, each member should have control of the agenda, that is, members should have the exclusive opportunity to decide upon the agenda and change it.

Fifth, democratic decision-making should include all adults. All (or at least most) adult permanent residents should have the full rights of citizens that are implied by the first four criteria.

From An Introduction to the Human Development and Capability Approach“, Ch. 8 – “Democracy and Political Participation”.

Poll worker explains voting process in southern Sudan referendum.jpg
Poll worker explains voting process in southern Sudan referendum” by USAID Africa Bureau via Wikimedia Commons.

It is striking that, despite talking a lot about freedom, and often being interested in the question of who controls power, these five criteria might as well be (Athenian) Greek to most free software communities and participants- the question of liberty begins and ends with source code, and has nothing to say about organizational structure and decision-making – critical questions serious philosophers always address.

Our licensing, of course, means that in theory points #4 and #5 are satisfied, but saying “you can submit a patch” is, for most people, roughly as satisfying as saying “you could buy a TV ad” to an American voter concerned about the impact of wealth on our elections. Yes, we all have the theoretical option to buy a TV ad/edit our code, but for most voters/users of software that option will always remain theoretical. We’re probably even further from satisfying #1, #2, and #3 in most projects, though one could see the Ada Initiative and GNOME OPW as attempts to deal with some aspects of #1, #3, and #4

This is not to say that voting is the right way to make decisions about software development, but simply to ask: if we don’t have these checks in place, what are we doing instead? And are those alternatives good enough for us to have certainty that we’re actually enhancing freedom?

Syndicated 2014-06-21 19:31:19 from Luis Villa » Blog

I am the CADT; and advice on NEEDINFOing old bugs en masse

[Attention conservation notice: probably not of interest to lawyers; this is about my previous life in software development.]

<a href="https://commons.wikimedia.org/wiki/File:MW_Bug_Squad_Barnstar.svg">Bugsquad barnstar, under MPL 1.1</a>
Bugsquad barnstar, under MPL 1.1

Someone recently mentioned JWZ’s old post on the CADT (Cascade of Attention Deficit Teecnagers) development model, and that finally has pushed me to say:

I am the CADT.

I did the bug closure that triggered Jamie’s rant, and I wrote the text he quotes in his blog post.1

Jamie got some things right, and some things wrong. The main thing he got right is that it is entirely possible to get into a cycle where instead of seriously trying to fix bugs, you just do a rewrite and cross your fingers that it fixes old bugs. And yes, this can particularly happen when you’re young and writing code for fun, where the joy of a from-scratch rewrite can overwhelm some of your other good senses. Jamie also got right that I communicated the issue pretty poorly. Consider this post a belated explanation (as well as a reference for the next time I see someone refer to CADT).

But that wasn’t what GNOME was doing when Jamie complained about it, and I doubt it is actually something that happens very often in any project large enough to have a large bug tracking system (BTS). So what were we doing?

First, as Brendan Eich has pointed out, sometimes a rewrite really is a good idea. GNOME 2 was such a rewrite – not only was a lot of the old code a hairy mess, we decided (correctly) to radically revise the old UI. So in that sense, the rewrite was not a “CADT” decision – the core bugs being fixed were the kinds of bugs that could only be fixed with massive, non-incremental change, rather than “hey, we got bored with the old code”. (Immediately afterwards, GNOME switched to time-based releases, and stuck to that schedule for the better part of a decade, which should be further proof we weren’t cascading.)

This meant there were several thousand old bugs that had been filed against UIs that no longer existed, and often against code that no longer existed or had been radically rewritten. So you’ve got new code and old bugs. What do you do with the old bugs?

It is important to know that open bugs in a BTS are not free. Old bugs impose a cost on developers, because when they are trying to search relevant bugs, old bugs can make it harder to find the things they really should be working on. In the best case, this slows them down; in the worst case, it drives them to use other tools to track the work they want to do – making the BTS next to useless. This violates rule #1 of a BTS: it must be useful for developers, or else it all falls apart.

So why did we choose to reduce these costs by closing bugs filed against the old codebase as NEEDINFO (and asking people to reopen if they were still relevant) instead of re-testing and re-triaging them one-by-one, as Jamie would have suggested? A few reasons:

  • number of triagers v. number of bugs: there were, at the time, around a half-dozen active bug volunteers, and thousands of pre-GNOME 2 bugs. It was simply unlikely that we’d ever be able to review all the old bugs even if we did nothing else.
  • focus on new bugs: new bugs are where triagers and developers are much more likely to be relevant – those bugs are against fresh code; the original filer is much more likely to respond to clarifying questions; etc. So all else being equal, time spent on new bugs was going to be much better for the software than time spent on old bugs.
  • steady flow of new bugs: if you’ve got a small number of new bugs coming in, perhaps you split your time – but we had no shortage of new bugs, nor of motivated bug reporters. So we may have paid some cost (by demotivating some reporters) but our scarce resource (developers) greatly appreciated it.
  • relative burden: with thousands of open bugs from thousands of reporters, it made sense to ask old them to test their bug against the new code. Reviewing their old bugs was a small burden for each of them, once we distributed it.

So when isn’t it a good idea to close ask for more information about old bugs?

  • Great at keeping old bugs triaged/relevant: If you have a very small number of old bugs that haven’t been touched in a long time, then they aren’t putting much burden on developers.
  • Slow code turnover: If your development process is such that it is highly likely that old bugs are still relevant (e.g., core has remained mostly untouched for many years, or effective use of TDD has kept the number of accidental new bugs low) this might not be a good idea.
  • No triggering event: In GNOME, there was a big event, plus a new influx of triagers, that made it make sense to do radical change. I wouldn’t recommend this “just because” – it should go hand-in-hand with other large changes, like a major release or important policy changes that will make future triaging more effective.

Relatedly, the team practices mailing list has been discussing good practices for migrating bug tracking systems in the past few days, which has been interesting to follow. I don’t take a strong position on where Wikimedia’s bugzilla falls on this point – Mediawiki has a fairly stable core, and the volume of incoming bugs may make triage of old bugs more plausible. But everyone running a very large bugzilla for an active project should remember that this is a part of their toolkit.

  1. Both had help from others, but it was eventually my decision.

Syndicated 2014-03-29 02:02:35 from Luis Villa » Blog

Summarizing “hacker legal education” crisply and cleanly

James Grimmelman is a better writer than I am. I already knew this, but in this commentary on Biella Coleman’s (excellent) Coding Freedom, he captures something I have struggled to express for years in two crisp, clean sentences:

Hacker legal education, with its roots in programming, is strong on formal precision and textual exegesis. But it is notably light on legal realism: coping with the open texture of the law and sorting persuasive from ineffective arguments.

This distinction is worth keeping in mind, for both sides of the professional/amateur legal discussion, to understand the relative strengths and weaknesses of their training and experience.

(Note that James says this, and I quote it, with all due love and respect, since we were both programmers before we were lawyers.)

Syndicated 2013-11-19 18:20:27 from Luis Villa » Blog

Some quick notes on the occasion of my fourth OSI board face-to-face

The past two days were my fourth OSI face-to-face board meeting, this time about a block from my office in San Francisco.

LAW_FOSSnetworking
Image by opensource.com under a CC BY-SA license.

 

Some brief thoughts:

  • I’m excited about the hire of our new General Manager (and first paid employee), Patrick Masson. One of the hardest things for an all-volunteer organization is execution: finishing the last 10% of tasks; reliably repeating necessary things; generally taking ideas from conception to reality. I expect in the short term that hiring Patrick will really help with those first two, and in the longer term, as he gets his feet under him, he’ll be a great help for the last one. Potentially a very exciting time for OSI.
  • Relatedly, we have a lot of proposals in the air, particularly with regards to membership and education/outreach. I hope in the next six months we’ll see a lot of concrete results from them.
  • This meeting represented a bit of  a changing of the guard — it was the first board meeting for Richard Fontana and the last for a long-time member of our community who will be term-limited out at the end of this term. I always enjoy working with Richard, and fresh blood is great, but it was a good reminder that time continues to pass and that I should focus on, you know, getting things done :)
  • This is a small thing, but the OSI website now has a brief summary of open source on the front page. We also recently helped a high-profile website update and correct their definition of open source – the kind of small thing that isn’t very visible but will be influential in the long run, as we educate the next wave of open source devs. Hoorah for small victories!
  • You can help (I): We continue to look for help to update the OSI website, both by improving our license information and by updating or writing other pages on the website.
  • You can help (II): Richard’s addition to the board is significant, because just like I was part of the first class of board members nominated by affiliates, he is the first board member elected by the membership. That is an important milestone for us, as we move towards being more accountable to, and governed by, the open source community. You can help by joining as an individual member, or by encouraging your organizations to join as an affiliate.
  • I continue to be grateful to the Wikimedia Foundation (and my boss!) in supporting me in doing this. There is never a good time to take two days mostly off.
  • The relationship between OSI and other groups promoting open definitions was a continued source of discussion at the meeting, and I imagine will continue to be a repeating theme. I hope I can continue to act as a bridge with organizations in open data and open culture, and I expect Patrick will be great in helping us bridge to open education.

Syndicated 2013-11-14 14:00:14 from Luis Villa » Blog

Reviewing the Manual of Style for Contract Drafting by Editing Twitter’s Patent Agreement

Synopsis for lawyers

You should really buy the Manual of Style for Contract Drafting – it’ll make you a better drafter and editor. This post applies the book’s rules and guidelines to a publicly-available legal agreement (Twitter’s Innovator’s Patent Agreement) to explain what the book is and why it is valuable.

tl;dr, for programmers

Contract writers have no equivalent of RFC 2119, mostly because contract drafting is hard. MSCD is a good try – defining terms and demanding consistency, just like the compiler lawyers lack. This post is a rewrite and fleshing out of the github edit history.

A contract for the selling of a field and a house.
A contract for the selling of a field and a house, from the Sumerian city of Shurrupak, now in the Louvre.

Introduction

I’ve believed for several years that the Manual of Style for Contract Drafting is a book that “every commercial lawyer should have on their desk“. You can judge the MSCD from its cover: it is aimed at people who draft contracts, attempting to teach them how to improve their writing style so that the contracts they create or negotiate are more legally precise, more concise, more enforceable, and easier to understand.

When Ken offered me a copy of the Third Edition for a book review, I jumped. But good reviews got written fast and I had nothing new or different to add. So I let the book review project sit for a while.

The thing is, once you’ve read MSCD, every time you read a legal document (even a good one!) you immediately start noticing small details that scream “MSCD would not approve”. So when I saw that Twitter’s Innovator’s Patent Agreement was on github, and started noticing those same small details, an idea was born: write a book review, in the form of public edits of the agreement.

This is that review. Quoted text is from the agreement, with additions in blue underscore and deletions struck through in red (following standard legal style for edits). Unfortunately, the original plan (simply copy the comments from the github edit history into the blog post) did not pan out, but if you’re comfortable with reading git histories, an un-massaged version of the review below is in my github account.

This is not about Twitter!

To be clear, this is a review of MSCD, not a critique of the Twitter IPA. The Twitter IPA was used simply to apply the book to a “real world” document and make it more tangible. The fact that you’ll see a bunch of edits below doesn’t mean the IPA is a bad document. Relative to some other documents I could name, including many I’ve written, this is actually a pretty small amount of edits. Because there are so many rules and suggestions (400+ pages of them!), applying MSCD to virtually any real-world contract will lead to a wall of edits. So this does not reflect badly on the drafters of the IPA, and shouldn’t be taken as a negative commentary on the substance of the agreement – which I think is important and innovative.

Note for non-lawyers

As I noted in the tldr, this book has a lot in common with RFC 2119 – the document that tells internet standards writers what words like “should”, “must”, “recommended”, etc., mean in the context of Internet Engineering Task Force memos. RFC 2119 is important to write a good standard, but at the same time, it is not a substitute for understanding of the relevant technology. Similarly, this book is about contract style – it can tell you how to fix language, but isn’t a substitute for actually understanding contract law or other bodies of law a contract might deal with, like IP. So don’t buy it and think it’ll turn you into a contract drafter :)

The Review

Key principles

The book opens with a discussion of key principles for contract drafting (the “Characteristics of Optimal Contract Language”). Most of these are Plain English Drafting 101 stuff, like “omit archaisms” and “omit problematic terms of art”, or “be precise” and “employ usages consistently”. None of them are rocket science. And yet, once you’ve read the rest of the book (and as you’ll see below), you’ll realize that most contract drafters mostly only pay lipservice to these principles. By elaborating these principles into extensive, highly detailed rules, MSCD will make you realize how badly most contracts violate some of these “obvious” things.

Organization and contract front matter

MSCD is very organized, in much the way you’d look at a contract – front to back (though not always). In that vein, chapter two covers the literal front of the contract – titles, introductory clauses, etc. It provides model language, ideal structures, and critiques traditional language; consistent with the rest of the book, it goes to an extreme level of detail to help drafters choose the exact best styles, consistent with the principles laid out in the first chapter. Applying these rules gives some sense of the flavor of the book as a whole.

For example, MSCD 2.110-113 discusses (and recommends against) the traditional use of a single word: the defined term “Agreement”, primarily on grounds that it is repetitious (violating one of the principles of chapter 1). In the IPA, removing the term highlights that it was defined, but never used – a common mistake. (This is a recurring theme: carefully applying the MSCD rules will not only catch the rules highlighted by MSCD, but also find other problems.)

This INNOVATOR’s PATENT AGREEMENT(“Agreement”) is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation] corporation, having a place of business at Company Address (“Company”).

Some MSCD rules are incredibly minor. For example, MSCD 2.18 recommends against using ALL CAPS in the first sentence, because that is already done in the title. There is literally no substantive change here, but it makes things read a little better – which adds up for long documents.

INNOVATOR’sS PATENT AGREEMENT (IPA), Version 1.0

This INNOVATOR’s PATENT AGREEMENTinnovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation] corporation, having a place of business at Company Address (“Company”).

MSCD tries hard to be comprehensive, but can’t. The principles of the first chapter, like MSCD 1.63-1.66, “Contract Language Should Employ Usages Consistently”, help fill in the gap. In the absence of a rule on how to do templating, my revised IPA sticks with [ALL CAPS AND BRACKETS] for values that should be filled in when the document is used.

This innovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation][STATE OF INCORPORATION] corporation, having a place of business at Company Address[COMPANY ADDRESS] (“Company”).

The book’s attention to detail can occasionally be maddening. But on the whole, I find it helpful. By forcing you to look again at “the way things have always been done”, it can help you see ways to improve contract clarity and make things more readable without sacrificing (and often improving) precision. As an example, MSCD 2.68 recommends against including the address of a party that is a registered legal entity, because the combination of the full official name + the jurisdiction in which the organization is registered should be sufficient to uniquely identify the organization. From Ken’s perspective, if you need the address for communication, put it in a section on notices – not the beginning of the contract. See also the general principles of MSCD 1.41-1.58, “Contract Language Should Omit Redundancy”.

This innovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation, having a place of business at [COMPANY ADDRESS] (“Company”).

MSCD discusses dating agreements (i.e., when does the agreement actually take effect?) in some depth in 2.21-2.45 and 5.3-5.7 (four pages of discussion). This type of recommendation is one of the areas where MSCD shines, since thinking about this once and adopting a standard, carefully considered, style can avoid a variety of problems. The change below gives the agreement a date (and related signature block) in accordance with MSCD’s recommended defaults, but users of the agreement might want to consult MSCD and amend the agreement appropriately to their situation. (This is one of the rare sections where the book admits of much flexibility – it is often quite rigid in its recommendations.)

MSCD’s recommendations usually, to my eye, improve readability. In one of the few recommendations that I find less readable, it recommends the wordier phrase below to replace “Agreed to and accepted” as the closing line of the document. I use it because (1) I’m seeking in this experiment/book review to follow MSCD’s recommendations, not necessarily my own instincts; and (2) MSCD’s recommendations in this area seem well justified – you can find them at 5.8-5.22.

Note that, in the original intended use case of this document, the agreement may be dated in several other ways – for example, by submission to the patent office. However, as it is usually good form to date stand-alone agreements, I’ve included these terms here, whether or not strictly necessary.

In the opening:

This innovator’s patent agreement is dated [DATE] and is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation (“Company”).

In the closing of the contract:

AGREED TO AND ACCEPTED:The parties are signing this agreement on the date stated in the introductory clause.

Strict application of MSCD while editing someone else’s contract would lead to horrible overkill, even when the recommendations are often well grounded. As an example, MSCD 2.46 recommends “between” as the preposition in the introductory clause, correctly calling traditional alternatives like ‘by and between’ “silly couplets” (a sign of legalese discussed in MSCD 1.42), and also rejecting the “made between” used in the IPA.

No sane negotiator would quibble over “made between”, “by and between”, and “between”. However, it is also a good example of where internalizing MSCD’s arguments will encourage you to be concise. A word here, a word there- it adds up over time.

This innovator’s patent agreement is dated [DATE], and is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation (“Company”).

Recitals, archaisms, and categorizing types of language

WHEREAS, using WHEREAS in recitals is archaic legalese, and WHEREAS avoiding archaisms is another principle all lawyers would tell you they endorse, and virtually none practice, and WHEREAS MSCD recommends not using whereas (MSCD 2.128), I have removed it from the IPA’s recitals, and used proper sentence structure (2.129).

In discussion of recitals, MSCD uses a technique that recurs throughout the book: intense, specific, precise categorization, based on usage and purpose, with matching commentary and style guidelines. Recitals, for example, are categorized into “purpose” recitals, “context” recitals, and “simultaneous transaction” recitals, and then rules are provided for each. The IPA’s recital falls into the category of “purpose” recitals: indicating why the parties want to do this deal (2.118). Based on this categorization, MSCD suggests using ‘wants’ – which is “consistent with everyday English” – instead of the “oddly steamy” ‘desires to’ (2.131-132).

[Were I editing for substance, I might add another sentence to explain why this particular agreement was used to reach the goal of assigning the invention.]

WHEREAS theThe Inventors have invented certain patentable subject matter whichmatter, and they desirewant to assign these inventions to the Company;.

When nitpicking is also substantive change

The next change is probably the first change that will make lawyers seriously nervous, because it removes the magic words “good and valuable consideration“. In a passage that is typical of the book, 2.149-2.164 of MSCD goes into some detail about why the traditional “recital of consideration” is unnecessary, and what it should be replaced by. As is common where the book is at its best, the discussion doesn’t merely say “these are bad, you should remove them”, but instead discusses background law (the Restatements and caselaw), and explains why they support Ken’s conclusions. It also lectures the courts on what they should do, which I find tiresome. (Certainly not the only legal treatise with that problem.)

In one of MSCD’s many suggestions that should be common sense, but isn’t, the book recommends that if there is some doubt as to whether or not there actually is consideration, the magic words should be replaced with an explicit discussion of what the consideration actually is. I have left that out here because it is a more substantive question, but it would be something for Twitter’s lawyers to consider if they ever considered adopting my changes.

NOW, THEREFORE, for good and valuable consideration, the receipt of which is hereby acknowledged, theThe parties therefore agree as follows:

Specific words and the MSCD index

While diving into the IPA’s definitions, we can start seeing more of MSCD’s attention to detail by looking at the legal-ism “hereof”. MSCD hits on hereof in three places – 4.92, 13.260, and 15.12. The relevant one here is 13.260, which simply recommends avoiding all “here-” and “there-” words, correctly calling them “one of the hallmarks of legalese.” (See below for more discussion of herein.)

This sort of thing is one of the strengths of the book. Almost a third of the book is Chapter 13, a list of words and phrases, with advice on how best to use every single one. Much of it does not apply to the admirably simple IPA, but most contracts will hit on a number of the words and benefit from reading the advice.

Note that this change also uses “the date of this agreement” as part of the replacement for “hereof” because, for simplicity and readability, MSCD 2.28 recommends using “the date of this agreement” rather than the traditional “Effective Date”.

“Affiliate” means with respect to any Entity, any other Entity, whether or not existing on the date hereof,of this agreement, controlling controlled by or under common control with such first Entity.

MSCD 13.376 is quite clear: no latinisms, except the most basic ones – pro rata, status quo, vice versa. This is a good example of how following MSCD will make documents more readable not just for other lawyers, but also for non-lawyers as well.

Any sublicense granted by the Inventors under this section must be without threat or additional consideration; otherwise, the sublicense will be considered void ab initio.from the beginning.

Relatedly, MSCD’s index is excellent and really key to using MSCD well: once you’ve gone through the book once and have internalized the important points, you can use the index every time you’re unsure of a specific phrase or concept. So, here, I saw “hereof”, thought “I’m pretty sure MSCD has a discussion of ‘hereof’”, and used the index to quickly find and review the discussion. Certainly, the index is what made this review possible!

Categories of contract language: performance, declaration, obligation

Chapter 3 of the book is about “categories of contract language”, where different categories (like language of agreement, of obligation, and of performance) are identified, and rules (and examples) set out for each one. Language of performance is highlighted as the kind of thing that the contract itself causes to occur. No less than 16 different commonly used ways of expressing this are identified and graded from “avoid” to “recommended.” “Hereby” comes out on top (“recommended”), and above “do hereby”. Once you’ve read his analysis, you’ll probably agree it’s the best way to express that the contract itself causes the action to occur. So I use it here, despite it being an archaic “here” word.

To me, breaking down language into categories like this (and others like them) are MSCD’s most useful mental discipline, because they help me think through exactly what I want a given clause to do, and then they give me the right language to do it with.

[Again, trying to stick to edits MSCD specifically recommends. Here, the mixed-tense 'sell'/'have sold' language is very unclear and unusual, and could probably stand to be rethought or removed, but is not, as far as I can tell, a clear MSCD violation.]

1. Subject to the terms and conditions herein, Inventors do hereby sell, assign, and transfer and have sold, assigned, and transferred to the Company, for itself and its successors, transferees, and assignees, the entire worldwide right, title, and interest in and to the following patent application(s):

Another category of contract language that MSCD goes into in some depth is “language of declaration” – i.e., language used by the parties to declare facts. This category is then further split into statements – used when one party wants to assert that a statement is accurate – and acknowledgements – used when one party wants the other to admit knowledge and accuracy of a statement.

Lawyers traditionally use “represents and warrants” to handle statements, but MSCD goes on at great length (citing caselaw, the UCC, and a few dictionaries) as to why this is a bad idea, and why “states” should be used instead. Importantly, he emphasizes that relying on “represents” to trigger a specific sort of remedy is unreliable, and that instead contract drafters should be explicit about what remedies they expect and how they will be enforced. (You can get the flavor of the argument, and his approach throughout the book, in Ken’s blog post on the issue.) Changing it here is a reminder that the book will make some lawyers uncomfortable (by challenging ritual word use) and can help drafting (by encouraging drafters to be precise and explicit about things like remedies). A more full rewrite of IPA could carefully consider the remedy question, though I tend to think that given the structure of the IPA it is not a substantive problem with the agreement.

Inventors representstate that Inventors have the rights, titles, and interests to convey as set forth herein; and Inventors covenant with Assignee that Inventors have not made and will not make any assignment, grant, mortgage, license, or other agreement affecting the rights, titles, and interests herein conveyed, except as explicitly set forth herein.

The other part of language of declaration – acknowledgement – is traditionally handled with “acknowledge and agree”. MSCD 3.318 (and 3.18) points out that the parties already “agree” to everything in the agreement in the opening of the contract, so “acknowledge and agree” later in the contract is redundant. (Redundancy is, correctly, another key sin MSCD acolytes hate.) This edit changes both “acknowledges and agrees” to simply “acknowledges”, and also removes a redundant “Inventors agree that”.

Inventors agree that Assignee may apply for and receive patents for Subject Matter in Assignee’s own name. Assignee acknowledges and agrees that the above promises are intended to run with the Patents and are binding on any future owner, assignee or exclusive licensee who has been given the right to enforce any claims of the Patents against third parties.

Assignee acknowledges and agrees that the promises in section 2 and 4 are intended to benefit third parties, except in the case of an assertion of claims of the Patents authorized under section 2.

“Language of obligation” is, not surprisingly, a key category of contract language, and one that MSCD goes into in some depth. One of the key recommendations on “language of obligation” is careful precision about what word is used to indicate obligation, which most contract drafters are somewhat sloppy about – sometimes using shall, sometimes using will, sometimes using must, without particular rhyme or reason.

MSCD 3.46-3.85 recommends using “shall” instead of “agree to” to indicate when one party is obligated to – has a duty to – another. This is one of the few places where a post-MSCD contract will look more like legalese, but again, the justification is thorough and persuasive. Following this recommendation, I have removed two instances of “agree to”. The same analysis of language of obligation also recommends many places where shall should not be used- this same change removes two of those uses.

2. The Company, on behalf of itself and its successors, transferees, and assignees (collectively the “Assignee”), agreesshall notto assert any claims of any Patents which may be granted on any of the above applications unless asserted for a Defensive Purpose. An assertion of claims of the Patents shall be consideredis for a “Defensive Purpose” if the claims are asserted:

3. Inventors agree that Assignee may apply for and receive patents for Subject Matter in Assignee’s own name. Inventors agree,shall, when requested, and without further consideration,to execute all papers necessary to fully secure to Assignee the rights, titles and interests herein conveyed.

This license to the Inventors is not assignable, although the license shallwill pass to the heirs of an Inventor in the case that the Inventor is deceased, and the Inventors, individually or jointly, may appoint a representative who may act on their behalf in granting sublicenses under this section.

“Covenants to” also falls afoul of Ken’s sword as a poor choice for language of obligation (3.86). Here I remove it, though the usages in the IPA are somewhat unusual and so tricky to replace.

Assignee covenants with Inventors thatshall encumber any assignment or transfer of its right, title, or interest herein will be conveyed with the promises herein as an encumbrance.

3. Inventors state that Inventorsthey have the rights, titles, and interests to convey as set forth herein; and. Inventors covenant with Assigneestate that Inventorsthey have not made, and willshall not make, any assignment, grant, mortgage, license, or other agreement affecting the rights, titles, and interests herein conveyed, except as explicitly set forth herein.

Ambiguity and Uncertainty

All of chapter 11 of MSCD is devoted to “the ambiguity of the part versus the whole” – essentially, the many ways that a drafter can make mistakes when trying to discuss parts of a whole (i.e., selling some parts, but not others, or making sure you sell all parts, or…). The section includes an interesting case study of a Third Circuit case, showing how drafters can very easily confuse judges. The change below is an attempt to remedy such an ambiguity in the IPA. “Each” (MSCD 11.83) appears to be the best way to cover the intent of the authors here, but “all” would probably also work and be consistent with the rest of the section.

(a) any and alleach inventions and improvements (“Subject Matter”) disclosed therein;

Chapter 11 isn’t the only single-minded chapter of that sort. Chapter 8 is devoted entirely to practical and scholarly discussion of the many variants of “reasonable efforts”, Chapter 9 to “material”, Chapter 10 to “references to time”, and Chapter 18 to “amendments”. Each one will show you flaws with common language and how to improve it.

Chapter 7 is another, critical one – “Sources of Uncertainty in Contract Language”. Among the categories of uncertainty are lexical ambiguity, antecedent ambiguity, undue generality, and conflict. IPA mostly avoids these problems, but not always. For example, it uses “herein” throughout the agreement. Besides being a “here” word (discussed above) in many places it was unclear what the “herein” referred to – was it a specific section? the entire agreement? This is an example of the antecedent ambiguity Chapter 7 warns about. The same happens with the “promises” made in Sec. 2, which are referred to throughout the document, but never actually named or described in Sec. 2. A hacky solution would be to say “The Company promises” rather than the original “The Company agrees” (original language) or “The Company shall” (my language). A better solution might be to break up Sec. 2 into smaller sections and have one section that consists entirely of the “promises”, titled/named appropriately and then refered to by the rest of the document.

Structuring the document

MSCD has extensive discussion of how documents should be structured (Chapter 4). Because of the overall simplicity of this document, I have not changed much. However, it recommends providing headings for sections (MSCD 4.15-21). As with many of the things that seem nitpicky at first, attempting to apply MSCD’s rules can expose substantive problems. In this change, I drafted headings for each section, but my attempt to write a meaningful heading for Sec. 3 suggests that it is not well-organized, and could be usefully split up into smaller sections. (A common problem; I ran into it with MPL.)

1. Assignment of Applications, Inventions, and Patents.
2. Limits on Assertion of Patents.
3. Patent Details.
4. License for Enforcement.

The same chapter’s discussion of enumerated clauses (MSCD 4.28-4.37) is (for me) one of the weaker sections in MSCD, because it is not entirely clear how to consistently apply them. In this case I have split up the list of (a), (b), etc. in Sec. 1 by adding a colon and made formatting changes (not shown here) to make the formatting consistent with the next section. This consistency makes it more obvious that “therein” and “thereto” are used in subparts (a) and (c) but “the above applications” in (b) and (d) – a problem I have not yet fixed, but a good example of how better typography and structuring can lead to better understanding of the text. It also makes more obvious that it is unclear whether the defined term “Patents” includes sections (b) and (c) – a potentially significant ambiguity in the text that should probably be resolved.

including:

Defined Terms

MSCD’s chapter on Defined Terms covers a variety of topics, including location and structure of definitions. It also recommends against the common practice of redundantly defining singular and plural terms (like “‘Inventor’ or ‘Inventors’ means…”) on the sensible ground that the less redundant definition “wouldn’t confuse a reasonable reader”. Here the IPA follows the correct MSCD behavior, but checking MSCD’s rule led to a change fixing the capitalization of “inventor” in Sec. 4, likely an actual bug in the IPA.

Any sublicense granted by the Inventors under this section must be without threat or additional consideration; otherwise, the sublicense will be considered void ab initio. This license to the Inventors is not assignable, although the license shall pass to the heirs of an inventorInventor in the case that the inventorInventor is deceased, and the inventors,Inventors, individually or jointly, may appoint a representative who may act on their behalf in granting sublicenses under this section.

Other Considerations

It is important to note that there are a variety of things I haven’t done here. I haven’t, for example, touched much substantively – I haven’t analyzed the validity of the patent grants. MSCD will not help you with this; it is not a substitute for substantive knowledge of the legal field you’re drafting the agreement in.

I also haven’t touched some of the more complex drafting questions. For example, MSCD correctly points out that many “triplets” are redundant and reflect drafting that sounds pretty but is not legally precise. At the same time, without deep knowledge of the field, you often can’t winnow them down. So a careful MSCD reader will treat these as a warning flag and do more careful analysis. IPA has a few of these warning-flag triplets: “sell, assign, and transfer”, “successors, transferees, and assignees”, “right, title, and interest”. But it is out of the scope of this review to actually see if some of these words could be winnowed out.

Similarly, the book has an extensive discussion of definitions – how they should be used, where they should be placed. Because of the structure of the IPA, “Defensive Purpose” (a key concept) is structured as a definition. I suspect that a truly thorough review of the document would have restructured that (based in part on an MSCD-driven analysis) though I can’t say for sure.

Finally, this has just not been comprehensive. MSCD’s appendices have a sample edit, similar to this one, identifying 209 changes in a six page document. So you can really, really dig down if you want to, and I’m guessing Ken (if he reads this review) would have much more to say about it!

Conclusion

This review really just scratches the surface of what MSCD can do for a drafter, but I think it yields a more readable, more correct document. It has to be taken with a grain of salt in places, but overall, the conclusion of this review is simple: everyone who writes or negotiates contracts for a living should buy and read it. Even if you apply only 1% of it, your contracts will be better than they were before.

Syndicated 2013-10-07 00:05:15 from Luis Villa » Blog

Thoughts on the CC Summit

I was lucky enough to attend the Creative Commons Global Summit in Buenos Aires last week, including the pre-conference session on copyright reform.

Oliver's Tattoo (cropped), by Oliver Keyes, used under CC BY-SA
Oliver’s Tattoo (cropped), by Oliver Keyes, used under CC BY-SA

Like Wikimania, there is simply too much here to summarize in coherent chunks, so here are my motes and thoughts during my return flight:

  • Maira Sutton of EFF summed up my strongest feeling about the event (and Wikimania, and many others) quite perfectly: “Getting a chance to finally meet those people you’ve admired from the Internet… Yea I hope that never gets old.” I hope I always remember that we are parts of a movement that draws much of its strength from being human – from being, simply, good to each other, and enjoying that. I realize sometimes being a lawyer gets in the way of that, but hopefully not too often ;)
  • At the copyright reform mini-conference, it was super-interesting to see the mix of countries playing offense and defense on copyright reform. Reform efforts discussed appeared to be patchwork; i.e., folks asking for one thing in one country, another in others, varying a great deal based on local circumstances. (The one “global” proposed solution was from American University/InfoJustice, who have worked with a team of lawyers from around the world to create a sort of global fair use/fair dealing exception called flexible use. An interesting idea.) Judging from my conversations at Wikimania and with Wikipedians at CC Summit, this is an area of great interest to Wikipedians, and possibly one where we could have a great impact as an example of the benefits of peer production.
  • Conversation around the revised CC 4.0 license drafts was mostly quite positive. The primary expressed concerns were about fragmentation and cross-jurisdictional compatibility. I understand these concerns better now, having engaged in several good discussions about them with folks at the conference. That said, I came away only confirmed on my core position on CC’s license drafting: when in doubt, CC should always err on the side of creating a global license and enabling low-complexity sharing.
  • This is not to say CC should rush things for 4.0, or be legally imprecise – just that they must be careful not to accidentally overlook the negative costs or overlawyering. Unfortunately, creating something knowingly imperfect is a profoundly difficult position for a lawyer to be in; something we’re trained to avoid at almost all costs. It is easiest to be in this position when there is an active negotiator on the other side, since they can actively persuade you about the compromise – instead of arguing against yourself. Public license drafting is perhaps unusually susceptible to causing this problem in lawyers; I do not envy the 4.0 drafters their difficult task.
  • There was a fair bit of (correct) complaining about the definition about Effective Technological Measures in the license – the most lawyerly piece of writing in 3.0 and the current drafts. Unfortunately, this is inevitable – to create a new, independent definition, instead of referring to the statute, is to risk protecting too much or too little, neither of which would be the correct outcome for CC. It would also make the license much longer than it currently is. I believe that the right solution is to drop the definition, and instead have a parallel distribution clause, where the important definition is easy: the recipient must be able to obtain at least one copy in which they are not prohibited from exercising the rights already defined. ETM then becomes much less important to define precisely.
  • Interesting to see that the distribution of licenses is mostly getting more free over time. After seeing the focuses of the various Creative Commons affiliates, I think this is probably not coincidence – they all seem quite dedicated to educating governments, OERs, and others about transaction costs associated with less free licenses, and many report good results.
  • That said, licensing data, even under free licenses, is going to be tricky – the trend there appears to be (at least) attribution, not disclaimer of rights. Attribution will be complicated for database integration; both from an engineering and a legal perspective.
  • Combined with the push towards government/institutional publication of data, there were a lot of talks and discussions about what to do with information that are difficult or inappropriate to edit, like scientific articles or historical documents. Lots of people think there is a lot of value to be added by tools that allow collaborative annotation and discussion, even on documents that can’t/shouldn’t be collaboratively edited. I think this could be a Wiki strength, if we built (or borrowed) the right tools, and I really hope we start on that soon.
  • Great energy in general from the affiliates around two areas: copyright reform, and encouragement of government and institutions to use CC licenses. I think these issues, and not the licenses themselves, will really be what drives the affiliates in the next 3-5 years. Remains to be seen where exactly CC HQ will fit into these issues – they are building a great team around OER, and announced support for copyright reform, but these are hard issues to lead from the center on, because they often need such specific, local knowledge.
  • Met lots of great people; too many to list here, but particularly great conversations with Prodi, Rafael, and folks from PLOS (who I think Wiki should partner with more). And of course catching up with a lot of old friends as well. In particular, perhaps my conversation with Kragen will spur me to finish my long-incomplete essay on Sen and Stallman.
  • I also had a particularly great conversation with my oldest friend, Dan, about what a modern-day attribution looks like. Now that we’re no longer limited to static textual lists of authors, as we have done since the dawn of the book, what can we do? How do we scale to mega-collaborative documents (like the Harry Potter page) that have hundreds or thousands of authors? How do we make it more two-way, so that there is not just formal attribution but genuine appreciation flowing both ways (without, of course, creating new frictions)? The “thanks” feature we’ve added to Wikipedia seems one small way to do this; Dan spoke also of how retweets simultaneously attribute and thank. But both of those are in walled silos- how can we take them outside of that?
  • Saw a great talk on “Copyright Exceptions in the Arab World” pan-Arab survey; really drove home how fragmented copyright statutes can be globally. (Translation, in particular, seemed an important and powerful exception, though my favorite exception was for military bands.) Of course, the practical impact of this is nearly nil – many of the organizations that are in charge of administering these literally don’t know they exist, and of course most of the people using the copyrights in the culture not only don’t know, they don’t care.
  • Beatriz Busaniche gave a nice talk; perhaps the most important single thing to me: a reminder that we should remember that even today most cultural communication takes place outside of (intentional) copyright.
  • Lessig is still Lessig; a powerful, clear, lucid speaker. We need more like him. In that vein, and after a late-night discussion about this exact topic, I remind speakers that before their next conference they should read Presentation Zen and Slideology.
  • Database rights session was interesting and informative, but perhaps did not ultimately move the ball forward very much. I fear that the situation is too complex, and the underlying legal concepts still too immature, for the big “add database to share-alike” step that CC is now committed to taking with 4.0. My initial impression (still subject to more research) is that Wikipedia’s factual and jurisdictional situation will avoid problems for us, but it may be worse for others.
  • After seeing all the energy from affiliates, as well as seeing it in Wikimedia’s community, I’m really curious about how innovation tends to happen in global NGOs like Red Cross or Greenpeace. Do national-level organizations discover issues and bring them to the center? Or is it primarily the center spotting issues (and solutions) and spurring the affiliates onward? Some mix? Obviously early CC was the former (Lessig personifies leadership from a center outwards) but the current CC seems to lean towards the latter. (This isn’t necessarily a bad place to be – it can simply reflect, as I think it does here, that the local affiliates are more optimistic and creative because they are closer to conditions on the ground.)
  • Watched two Baz Luhrmann films on my flight back, a fun reminder of the power of remix. I know most of my film friends think he’s awful, and admittedly for the first time I realized that Clair Danes is … not very good … in Romeo and Juliet. But in Luhrmann there is a zest, a gleeful chopping, mixing, and recreating of our culture. And I love that; I hope CC can help enable that for the next generation of Luhrmanns.

Syndicated 2013-08-29 13:30:50 from Luis Villa » Blog

I’m Donating to the Ada Initiative, and You Should Too

I was going to write a long, involved post about why I donated again to the Ada Initiative, and why you should too, especially in the concluding days of this year’s fundraising drive (which ends Friday).

Lady Ada Lovelace, by Alfred Edward Chalon [Public domain], via Wikimedia Commons
But instead Jacob Kaplan-Moss said it better than I can. Some key bits:

I’m been working with (and on) open source software for over half my life, and open source has been incredibly good for me. The best things in my life — a career I love, the ability to live how and where I want, opportunities to travel around the world — they’ve all been a direct result of the open source communities I’ve become involved in.

I’m male, so I get to take advantage of the assumed competency our industry heaps on men. … I’ve never had my ideas poached by other men, something that happens to women all the time. … I’ve never been refused a job out of fears that I might get pregnant. I can go to conferences without worrying I might be harassed or raped.

So, I’ve been incredibly successful making a life out of open source, but I’m playing on the lowest difficulty setting there is.

This needs to change.

Amen to all that. The Ada Initiative is not enough – each of us needs to dig into the problem ourselves, not just delegate to others. But Ada is an important tool we have to attack the problem, doing great work to discuss, evangelize, and provide support. I hope you’ll join me (and Jacob, and many other people) in doing our part to support it in turn.
Donate now

Syndicated 2013-08-28 13:00:19 from Luis Villa » Blog

Final(?) Wikimania 2013 idea and notes dump

Luis at Victoria Peak, the morning after
Me at Victoria Peak, the day after Wikimania, with thanks to Coren.

More random, more-or-less stream-of-(un)consciousness notes on the last few days of Wikimania:

  • The cab driver who got me to the airport had (at least) five cellphones. Two were mounted on each side of the steering wheel, and then a fifth appeared from somewhere else half-way through our drive to the airport. Two were Android(-ish?) smartphones, the others older phones. I’m sure there is some perfectly good reason for this, but no idea what it could be.
  • I had been under the impression that the island was essentially entirely either built up or too vertical to build on, so I had wondered how they’d managed to squeeze an entire Disneyland in there. Now I know; it is really quite amazing how much green, open space there is.
  • I was glad to hear Sue say that she cried while watching the South African Wikipedia Zero video, because I did too. As did lots of others, apparently. Still such a long way to reach the 13 out of 14 people on Earth who don’t use us every month, and so many different challenges to surmount – first access, then language, then engagement… oof. But obviously a worth challenge.
  • The 7-11s and Starbucks everywhere in HK are a reminder that the lines between national cultures are blurring faster than they ever have. I still got chicken feet as an unrequested pre-dinner appetizer one night, and unidentifiable fungus of some sort another afternoon. And I did get to see the very interesting, traditional Man Mo temple. But the trend is in favor of homogenization. This is in some ways very sad, as distinctive cultures make the world a richer place, but it will also over the long run make it easier for various contributors to understand each other – the classic mixed bag.
  • At the same time, was reminded in a few ways that barriers to communication are often surprisingly high- for example, a Chinese Wikipedian asked me (quite earnestly) about whether people disagreed about edits on English Wikipedia, which suggested we’re not very good at communicating to new Wikipedians in other languages even the most basic facts. (Asking “do English Wikipedians argue” feels to me like asking “is the sky blue for English Wikipedians?” – almost inconceivable that we haven’t already communicated that.)
  • Chinese Wikipedians are also working on an “intro to Wikipedia editing” tutorial that looks pretty cool. Made me sort of wonder if translating the newly-released How WP Works wikibook (or perhaps a shortened version of same?) might be a good/useful project for young Wiki movements, or if it is better to learn the same lessons through trial and error?
  • The German chapter has three policy people; the Foundation has zero (though all WMF’s lawyers pitch in on policy issues from time to time). I had sort of known this before, but not really internalized it. Still thinking through what that implies. (I had many great conversations with a bunch of the German chapter, and look forward to working with many of them.)
  • Very curious about the economics of the Octopus card. My impression as an outsider is that, through the Octopus cards, Hong Kong has established a defacto digital standard currency without relying on the inefficient, uninnovative, tax-on-the-body-politic leeches known as Visa and Mastercard. But that sounds too good to be true; there must be a catch to it.
  • Several Germans raved about the efficiency, politeness, etc. of the Hong Kong medical system. I chalk this up as a point for the Matt Yglesias “how government services are delivered and executed matters a lot and the US government should pay a lot more attention to that” school of thought.
  • The London organizers are extremely Bold; I wish them great luck in their planning and endeavors. I don’t think it’ll hurt the core conference to try these new experiments, and the payoff if it works could be huge, but I can understand the trepidation on the part of many long-time Wikimaniacs.
  • Had the opportunity to talk to a great variety of people who are passionate about the project; most who were excited and optimistic, some really concerned for a variety of reasons. I hope, of course, with my lawyer hat on, that I was able to calm those fears; in the mean time, it was a good reminder of the depth of passion for the project. (This was one of the many ways where I felt right at home, coming from years of GUADECs- the passion is real and deep and unfakeable in both places.)
  • That said, my biggest personal goal for the conference was to meet a broad cross-section of the community, rather than just the usual suspects from chapters, the board, etc. I feel like I had mixed achievement in this respect- I did have some pretty good conversations with non-chapter, non- (especially with people I met in line for food!) but at the end it was hard to do quite as much of it as I would have liked, especially for non-hacker folks. (The hacking days before the conference made meeting hackers much easier for me than it was to meet non-hacker editors.)
  • This really drove home that in the future, when I go somewhere for a non-Wiki conference, I really need to drop the local village pump or other comms channel an email and see if there is a meetup, editathon, etc. that I can crash.
  • We are deeply adaptable creatures, of course; I was quite overwhelmed by Hong Kong on day one and reasonably comfortable running around it on the free half-day I had before I flew home, and wish I’d had more time tosee it.  Still, it seems to me a city that would be very difficult for me to live happily in without gigantic piles of money.
  • Surprising to me to realize (once it was pointed out by Mako) that many WP articles about a place don’t have a clear link to the equivalent WV page. That seems like low-hanging fruit; I found a couple Monday while seeing the town before my flight and will try to remember to fix them once I’m back on a real network connection.
  • Pretty happy with the two LCA team talks I was part of – we received a bunch of compliments on them, and many great questions from the audience. That said, I think we probably went too broad on the open licensing talk. It either needs to be narrower (only one license or class of licenses) or longer (time-wise) next year, if we make this subject an annual thing. But that is a quibble – overall, I’m pretty happy with the quality of my first impression.
  • I admit that I played buzzword bingo during the Board’s Q&A. I actually think it helped me pay attention to certain topics I might have zoned out a little bit on otherwise, which is good, but the fact that it seems to be played fairly widely may suggest something about the format. I’m not sure what I’d change, though – doing that sort of interaction really does seem like an important way to build trust in the board. (You can mark “social capital” off your Luis Blog Post Bingo card if you’ve read this far.)
  • The closing beach party was a lot of fun, but (with no slight intended to the HK organizers) the top for me will always be the various beach parties at GUADEC Vilanova. For those of you who weren’t there in Vilanova, imagine something like the WM party, but with the broadest beach I’ve ever seen in my whole life, the bar literally in the middle of the sand, and the bar open until 4am. Now that the bar has been raised, I look forward to London’s beach party! ;)
  • Real joy to meet Risker; reminder that these sorts of meetings really allow you to get context and build up a mental model of someone in a way that you just can’t do offline, which makes these soooo important.
  • Copyright reform was a constant and recurring theme of discussion. In six years, certain aspects of Mickey Mouse will start creeping into the public domain, and that means we’re going to have another copyright bill in that time period. I suspect that the as a movement have to be ready and prepared for that, shape and form To Be Determined.

Bottom line: I’m exhausted, and (as I hit my six-months-iversary) more glad than ever I took this plunge. :) See everyone in London!

Syndicated 2013-08-16 09:26:36 from Luis Villa » Blog

Wikimania, Day 3

Soooo much. As with the first two days, these are fragmentary notes as much for my benefit as for anyone else’s, so take with bullet points of salt:

Ceremonia_de_inauguración_de_Wikimania_2013,_Hong_Kong,_2013-08-09,_DD_20
Ceremonia de inauguración, by Diego Delso, used under CC BY-SA-3.0, via Wikimedia Commons
  • The lion dance in the opening ceremony was exactly as advertised – a good way to wake up.
  • It was nice to hear the French issue called out in Jimmy’s talk, even if he didn’t call out LCA’s role in it :)
  • The session on the internet in China was informative, but frustratingly brief- needs a lot more detail. Key takeaway: the mainland Chinese Wikipedians appear to believe that turning off http access would be a bad idea. This is a frustrating tension, between access and surveillance.
  • The talk on how Swedish parliamentarians see Wikimedia was not perfect science (response rates were low-ish and skewed in a variety of ways) but the data was still fun and informative. Key takeaways: MPs in .se have pretty positive feelings about WP, and high usage, but assume their co-workers do not have a high opinion of it themselves. I would love to see data similar to this for American politicians, and perhaps as importantly for political staffs.
  • The friendly virtual space policy discussion was interesting, but I am having to recalibrate my timescales and expectations of progress, just because of the vastness and multi-faceted-ness of this community. (At the same time I hope not to become accepting of inaction.)
  • Mako and Aaron’s Wiki Ecology talk was hard to summarize, but very interesting. So much research to be done to understand how FOSS and wiki ticks; I’m glad Mako is doing it.
  • Not all talks are home runs, unfortunately; I like Foucault as much as the next guy (and am quite sympathetic to the notion that pervasive recording influences behavior) but if it comes up in your talk focus may be an issue :)
  • The government copyright talk was interesting, and mostly informative. Good reminder that we should think about if/how to support the state-level government code freeing being done by Carl Malamud.
  • Hallway conversations are great; not surprising.
  • (More?) importantly, for the first time tonight had the great, long, passionate, late night conversations that make you want to say “can’t wait to have a beer with you again next year”. Had a long enough night that I had that kind of conversation with quite a series of people, actually.

Syndicated 2013-08-09 20:39:25 from Luis Villa » Blog

689 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!