Post Open Standards

Free/Libre/Open Formats/Protocols/Standards

2 great Document Freedom Day announcements

Thursday, March 26th, 2015

Yesterday (March 25) was again Document Freedom Day, a celebration of open standards. Rather than my usual critical cheering, this year I took to adding all of my pertinent posts to a free/libre/open formats/protocols/standards category and want to highlight two exciting announcements:

(1) IETF NetVC BoF notes, slides:

Goals for the Proposed WG

  • Development of a video codec that is:
    • Optimized for real-time communications over the public Internet
    • Competitive with or superior to existing modern codecs
    • Viewed as having IPR licensing terms that allow for wide implementation and deployment
    • Developed under the IPR rules in BCP 78 (RFC 5378) and BCP 79 (RFCs 3979 and 4879)
  • Replicate the success of the CODEC WG in producing the Opus audio codec.

For more on why this is exciting, see Opus! and “I would love it if all patents evaporated” (WebRTC). Appropriately, yesterday also brought another blog-like post (discussion) on the development of the Daala codec, which could form the basis of the hoped-for IETF standard.

(2) LibreOffice Online is coming. If successful it will fill a major gap in the free software product line. I worried about this gap the last time I congratulated LibreOffice on another release.

LegacyOffice?

Wednesday, July 30th, 2014

LibreOffice 4.3 announcement, release notes with new feature screenshots, developer perspective. Perhaps most useful, a feature comparison of LibreOffice 4.3 and Microsoft Office 2013.

Overall a great six month release. Coming early next year: 4.4.

Steady progress is also being made on policy. “The default format for saving [UK] government documents must be Open Document Format (ODF)” — the genuinely open standard used by LibreOffice; Glyn Moody has a good writeup. I occasionally see news of large organizations migrating to LibreOffice, most recently the city of Tolouse. Hopefully many more will manage to escape “effective captivity” to a single vendor (Glyn Moody for that story too).

(My take on the broad importance of open policy and software adoption.)

Also, recent news of work on a version of LibreOffice for Android. But nothing on LibreOffice Online (in a web browser) which as far as I can tell remains a prototype. WebODF is an independent implementation of ODF viewing and editing in browser. Any of these probably require lots of work to be as effective of a collaboration solution as Google Docs — much of the work outside the editing software, e.g. integration with “sharing” mechanisms (e.g., WebODF and ownCloud) and ready availability of deployments of those mechanisms (Sandstorm is promising recent work on deployment, especially security).

From what I observe, Google Docs has largely displaced (except for large or heavily formatted for print or facsimile) Microsoft Office, though I guess that’s not the case in large organizations with internal sharing mechanisms. I suspect Google Docs (especially spreadsheets) has also expanded the use of “office” software, in part replacing wiki use cases. Is there any reason to think that free/open source software isn’t as far behind now as it was in 2000 before the open source release of OpenOffice.org, LibreOffice’s predecessor?

Still, I consider LibreOffice one of the most important free software projects. I expect it will continue to be developed and used on millions of “legacy” desktops for decades after captivity to Microsoft is long past, indeed after desktop versions of Microsoft Office long EoL’d. Hopefully LibreOffice’s strong community, development, governance, and momentum (all vastly improved over OpenOffice.org) in combination with open policy work (almost non-existent in 2000) and other projects will obtain much better than even this valuable result.

{ "title" : "API commons II" }

Tuesday, June 24th, 2014

API Voice:

Those two posts by API Evangelist (another of his sites) Kin Lane extract bits of my long post on these and related matters, as discussed at API Con. I’m happy that even one person obtained such clear takeaways from reading my post or attending the panel.

Quick followups on Lane’s posts:

  • I failed to mention that never requiring permission to implement an API must include not needing permission to reverse engineer or discover an undocumented API. I do not know whether this implies in the context of web service APIs has been thoroughly explored.
  • Lane mentions a layer that I missed: the data model or schema. Or models, including for inputs and outputs of the API, and of whatever underlying data it is providing access to. These may fall out of other layers, or may be specified independently.
  • I reiterate my recommendation of the Apache License 2.0 as currently the best license for API specifications. But I really don’t want to argue with pushing CC0, which has great expressive value even if it isn’t absolutely perfect for the purpose (explicit non-licensing of patents).

API commons

Thursday, May 29th, 2014

Notes for panel The API Copyright Emergency: What’s Next? today at API Con SF. The “emergency” is the recent decision in Oracle v. Google, which I don’t discuss directly below, though I did riff on the ongoing case last year.

I begin with and come back to a few times Creative Commons licenses as I was on the panel as a “senior fellow” for that organization, but apart from such emphasis and framing, this is more or less what I think. I got about 80% of the below in on the panel, but hopefully still worth reading even for attendees.

A few follow-up thoughts after the notes.

Creative Commons licenses, like other public licenses, grant permissions around copyright, but as CC’s statement on copyright reform concludes, licenses “are not a substitute for users’ rights, and CC supports ongoing efforts to reform copyright law to strengthen users’ rights and expand the public domain.” In the context of APIs, default policy should be that independent implementation of an API never require permission from the API’s designer, previous implementer, or other rightsholder.

Without such a default policy of permission-free innovation, interoperability and competition will suffer, and the API community invites late and messy regulation at other levels intending to protect consumers from resulting lock-in.

Practically, there are things API developers, service providers, and API consumers can do and demand of each other, both to protect the community from a bad turn in default policy, and to go further in creating a commons. But using tools such as those CC provides, and choosing the right tools, requires looking at what an API consists of, including:

  1. API specification
  2. API documentation
  3. API implementations, server
  4. API implementations, client
  5. Material (often “data”) made available via API
  6. API metadata (e.g, as part of API directory)

(depending on construction, these could all be generated from an annotated implementation, or could each be separate works)

and what restrictions can be pertinent:

  1. Copyright
  2. Patent

(many other issues can arise from providing an API as a service, e.g., privacy, though those are usually not in the range of public licenses and are orthogonal to API “IP”, so I’ll ignore them here)

1-4 are clearly works subject to copyright, while 5 and 6 may or may not be (e.g., hopefully not if purely factual data). Typically only 3 and 4 might be restricted by patents.

Standards bodies typically do their work primarily around 1. Relatively open ones, like the W3C, obtain agreement from all contributors to the standard to permit royalty-free implementation of the standard by anyone, typically including a patent license and permission to prepare and perform derivative works (i.e., copyright, to extent such permission is necessary). One option you have is to put your API through an existing standards organization. This may be too heavyweight, or may be appropriate yet if your API is really a multi-stakeholder thing with multiple peer implementations; the W3C now has a lightweight community group venue which might be appropriate. The Open Web Foundation’s agreements allow you to take this approach for your API without involvement of an existing standards body​. Lawrence Rosen has/will talk about this.

Another approach is to release your API specification (and necessarily 2-4 to the extent they comprise one work, ideally even if they are separate) under a public copyright license, such as one of the CC licenses, the CC0 public domain dedication, or an open source software license. Currently the most obvious choice is the Apache License 2.0, which grants copyright permission as well as including a patent peace clause. One or more of the CC licenses are sometimes suggested, perhaps because specification and documentation are often one work, and the latter seems like a “creative” work. But keep in mind that CC does not recommend using its licenses for software, and instead recommends using an open source software licenses (such as Apache): no CC license includes explicit patent permission, and depending on the specific CC license chosen, it may not be compatible with software licenses, contrary to goal of granting clear permission for independent API implementation, even in the face of a bad policy turn.

One way to go beyond mitigating “API copyrightability” is to publish open source implementations, preferably production, though reference implementations are better than nothing. These implementations would be covered by whatever copyright and patent permissions are granted by the license they are released under — again Apache 2.0 is a good choice, and for software implementation CC licenses should not be used; other software licenses such as [A]GPL might be pertinent depending on business and social goals.

Another way to create a “thick” API commons is to address material made available via APIs, and metadata about APIs. There, CC tools are likely pertinent, e.g., use CC0 for data and metadata to ensure that “facts are free”, as they ought be in spite of other bad policy turns.

To get even thicker, consider the architecture, for lack of a better term, around API development, services, and material accessed and updated via APIs. Just some keywords: Linked Open Data, P2P, federation, Lots of Copies Keep Stuff Safe, collaborative curation.

The other panelists were Pamela Samuelson, Lawrence Rosen, and Annette Hurst, moderated by David Berlind.

I’m fairly familiar with Samuelson’s and Rosen’s work and don’t have comments on what they said on the panel. If you want to read more, I recommend among Samuelson’s papers The Strange Odyssey of Software Interfaces and Intellectual Property Law which shows that the “API copyright emergency” of the panel title is recurrent and intertwined with patent, providing several decades of the pertinent history up to 2008. Contrary to my expectation in the notes above, Rosen didn’t get a chance to talk about the Open Web Foundation agreements, but you can read his 2010 article Implementing Open Standards in Open Source which covers OWF.

Hurst is a lawyer for Orrick representing Oracle in the Oracle v. Google case, so understandably advocated for API copyright, but in the process made several deeply flawed assertions could have consumed the entire duration of the panel, but Berlind did a good job of keeping the conversation moving forward. Still, I want to mention two high level ones here, my paraphrases and responses:

Without software copyright the software economy would go away. This is refuted by software development not for the purposes of selling licenses (which is the vast majority of it), especially free/open source software development, and services (e.g., API provision, the source of which is often never published, though it ought be, see “going beyond” recommendations above). Yes the software economy would change, with less winner-take-all monopoly and less employment for Intellectual Parasite lawyers. But the software economy would be huge and very competitive. Software is eating the world, remember? One way to make it help rather than pejoratively eat the world is to eject the parasites along for the ride.

Open source can’t work without software copyright. This is refuted by 1) software source sharing before software copyright; 2) preponderance of permissively licensed open source software, in which the terms do not allow suing downstream developers who do not share back; 3) the difficulty of enforcing copyleft licenses which do allow for suing downstream developers who do not share back; 4) the possibility of non-copyright regulation to force sharing of source (indeed I see the charitable understanding of copyleft as prototyping such regulation; for perspective on the Oracle v. Google case from someone with a more purely charitable understanding of copyleft, see Bradley Kuhn); and 5) demand and supply mechanisms for mandating sharing of source (e.g., procurement policies, distribution policies such as Debian’s).

These came up because Hurst seemed to really want the audience to conflate software copyright in general (not at issue in the case, settled in a bad place since the early 1980s) and API copyright specifically. Regarding the latter, another point which could have been made is the extent to which free/open source software has been built around providing alternatives to proprietary software, often API-compatible. If API copyright could prevent compatible implementation without permission of any sort, open source, competition, and innovation would all be severely hampered.

There is a recent site called API Commons, which seems to be an API directory (Programmable Web, which ran the conference, also has one). My general suggestion to both would be to implement and facilitate putting all elements of APIs listed above in my notes in the commons. For example, they could clarify that API metadata they collect is in the public domain, publish it as Linked Open Data, and encourage API developers and providers they catalog to freely license specifications, documentation, implementations, and data, and note such in the directories.

In order to get a flavor for the conference, I listened to yesterday morning’s keynotes, both of which made valiant attempts to connect big picture themes to day to day API development and provision. Allow me to try to make connections back to “API commons”.

Sarah Austin, representing the San Francisco YMCA, pointed out that the conference is near the Tenderloin neighborhood, the poorest in central San Francisco. Austin asked if kids from the Tenderloin would be able to find jobs in the “API economy” or would they be priced out of the area (many tech companies have moved nearby in the last years, Twitter perhaps the best known).

Keith Axline claimed The Universe Is Programmable. We Need an API for Everything, or to some extent, that learning about the universe and how to manipulate it is like programming. Axline’s talk seemed fairly philosophical, but could be made concrete with reference to the Internet of Things, programmable matter, robots, nanobots, software eating the world … much about the world will indeed soon be software (programmable) or obsolete.

Axline’s conclusion was in effect largely about knowledge policy, including mourning energy wasted on IP, and observing that we should figure out public support for science or risk a programmable world dominated by IP. That might be part of it, but keeps the focus on funding, which is just where IP advocates want it — IP is an off-the-balance-sheets, “free” taking. A more direct approach is needed — get the rules of knowledge policy right, put freedom and equality as its top goals, reject freedom infringing regimes, promote commons (but mandating all these as a condition of public and publicly interested funding is a reasonable starting place) — given these objectives and constraints, then argue about market, government, or other failure and funding.

Knowledge policy can’t directly address the Austin’s concerns in the Tenderloin, but it does indirectly affect them, and over the long term tremendously affect them, in the Tenderloin and many other places. As the world accelerates its transition from an industrial to a knowledge dominated economy, will that economy be dominated by monopoly and inequality or freedom and equality? Will the former concentrations continue to abet instances of what Jane Jacobs called “catastrophic money” rushing into ill-prepared neighborhoods, or will the latter tendencies spread the knowledge, wealth, and opportunity?

Patent reform, parts deficient in commons

Friday, April 18th, 2014

A Five Part Plan for Patent Reform (pdf) by Charles Duan, Director of Patent Reform at Public Knowledge, is simultaneously good and deficient:

  1. Notes theoretical and observed problems with monopoly incentive story underlying patents, mixed empirical results, regulatory cause of strong positive results in one field (pharma), layers of abuse surrounding core in implementation, the existence of many non-monopoly incentives for innovation, conflicts between these and patents … and yet fundamentally accepts the noble origin role of monopoly incentives in protecting apple pie and correlation with some inventions — nevermind causality or counterfactual. Compare text “certainly many inventions through history, such as the light bulb, the airplane, and the photocopier, were invented by small inventors and protected by patents” and its citation (footnote 7, The Myth of the Sole Inventor)!
  2. Discusses commons (Open Innovation Communities) as evidence, and substantially better than typical writing doing so, as at least a concept of pro-commons reform is included: “One task for patent reform, then, is to consider adjustments to the patent system that better accommodate these alternate incentives for innovation. The goal of such adjustments is to better encourage these inventors incentivized by factors other than patents, and to ensure that patents do not stand in the way of those inventors.” As usual, commons regimes carved out of property defaults are mentioned (specifically GPL and DPL), but not as prototypes for default policy. Also, “it is important for these decisionmakers to reach out to inventing communities, even those that do not file for patents, and it is important for those communities to reach out to the Patent Office and other decisionmakers.” I think this also holds for “IP scholars” (which of course ought re-imagine themselves as commons scholars) and OIC participants/commoners — let’s talk about what concrete reforms would favor actually existing commons, and put those on the scholarly and policy agendas. A recent idea directly concerning patents that ought start down that long road, but many pertinent reforms may be indirect, favoring commons in other ways so as to change the knowledge economy which eventually determines what interests dominate.
  3. Innovation is assumed the top goal of policy, tempered only by conflict among incentives to innovate, and need to rein in unscrupulous behavior. No mention of freedom and almost none of equality (Joseph Stiglitz is quoted: “The alternative of awarding prizes would be more efficient and more equitable”), let alone as goals which trump innovation.

These three good/deficient pairs are endemic in intellectual property-focused discourse, e.g., see my recent reviews of IP in a World Without Scarcity and Copyright and Inequality — one of the reasons the latter is so great is that places equality firmly on the agenda.

A few other notes on A Five Part Plan for Patent Reform:

  • It’s not a plan, rather an exploration of “five key areas in which the patent system is ripe for reform.” The word plan doesn’t even appear in the text. Well worth reading, but don’t expect to find an actionable plan with five parts.
  • Notes that patent trolls existed in the 1800s (individual farmers were bullied to pay royalties for farm implements covered by patents), which is good (too often current discourse assumes intellectual property worked just fine until recently, with conflict caused by changing technology rather than by power and rent seeking), but then: “Analogously, as discussed above, farm technology was widely used in the nineteenth century, and patents on farm technology were hotly contested. Patents on those farm tools were effectively abolished. But that fix to the patent system did not prevent the software patent problems faced today—it ultimately was a Band-Aid rather than a cure. The same would be true of eliminating software patents. The fundamental issue is that the technologies of tomorrow are unknown, so targeting patent reform to one specific field of technology means that the same problems will only arise again in a different technological sector.” Sure, only abolishing all patents is sufficient, but this analogy seriously undersells the benefit of abolishing software patents: agriculture then was in relative decline of importance in the face of industrialization. Now, software is ascendant, and any technology of tomorrow that matters will involve software.
  • Focuses on FRAND (fair, reasonable and non-discriminatory) licensing for standards. But RF (royalty free) licensing is required for any standard in which commons-based projects are first class participants (e.g., free/open source software and codec patents). No doubt unscrupulous behavior around FRAND and standards is a problem, but the solution is RF for standards.
  • From the Public Knowledge site, reading the paper requires first supplying an email address to a third party (gumroad). Annoying, but on par with PK’s newsletter practices (one of the many favoring tracking users at cost of usefulness to users). Better, the paper is released under CC-BY-SA, so I uploaded a copy to the Internet Archive. Best, Duan has published the paper’s LaTeX source.

Protect commons from patents

Friday, April 11th, 2014

Rob Landley has a good idea: software patents shouldn’t apply to public domain software. This is exactly the kind of commons-favoring reform that ought be topmost on the agenda of anyone who cares about a good [digital] future. It will take years for many such reforms to be feasible. This only means it is urgent for commoners of all free/open stripes to begin thinking of themselves collectively as a politically potent self-interested group, not as merely surviving through private opt-outs from increasingly bad regulation and reaction against apparent existential threats.

I’m a huge fan of the public domain and think that among private opt-outs, public domain instruments ought be used much more than they are. Landley makes an interesting case (historical and otherwise, read his full post) for limiting protection from software patents to public domain software rather than any free/open source software, but I disagree — in this reform step, it makes sense to protect developers and users of any free/open source software from patents with regard to that software.

Up to the last paragraph the rest of this post is dedicated to this disagreement (and in another sense of dedicated, to the public domain, as is everything by me), but don’t let that distract from my overall appreciation of Landley’s post — read the whole thing (his blog is also interesting overall, stylistically like early blogs, and it does have posts back to 2002, though I’ve only been following it approximately since the first link in previous paragraph: see link text “disagree”, appropriately enough).

Landley writes:

The reason to say “public domain” instead of “open source” is partly that open source is difficult to legally define

Public domain hasn’t got that problem. It avoids the whole can of worms of what is and isn’t: the code is out there with zero restrictions.

1) Existing law and regulation deals with “open source”, e.g. the U.S. Department of Defense and the Italian government. This is no significant obstacle. On the other hand, “public domain” has another problem: FUD about whether it is “legally possible” to put new works in the public domain and whether various public domain instruments “work”. This FUD needs to be combated, but I think it’ll be more effective to do so in part by getting public domain instruments recognized as free/open instruments by various gatekeepers than by dumping FUD on the same.

The price for freedom from patents should be zero restrictions: if the authors have no control over what people can do with it, why should uninvolved third parties have a say? Ideally the smooth, frictionless legal surface of the public domain should go both ways.

That’s the constitutional argument: freely redistributable, infinitely replicable code serves the stated constitutional purpose of copyrights and patents better than patents do. Releasing your copyrights into the public domain should also prevent patent claims on that code.

2) That’s a fine assertion, but it’s really outside the free/open source (and nearby) consensus on software patents: they should be abolished, i.e., one should not have to give up anything to be protected from them. Changing the focus to strategically demanding freedom from patents for free/open source software (while still agreeing they ought be abolished for all) would mark a huge shift in the imagination of the movement(s). Limiting the scope of protection to only public domain software: how is it imaginable to take that idea beyond an interesting blog post? I wish a huge constituency for public domain software existed, but as of now it is a rounding error.

3) Zero restrictions is a fine ideal (indeed, copyright and patent should be abolished entirely), but whether viewed as a “price” or grant of permissions, releasing work under any free/open license makes very significant grants. Attendant conditions may be annoying, self-defeating, necessary, or something else depending on one’s perspective (I try to view them charitably as prototypes for more effective regulation not based on copyright holder whim, but also think it is worthwhile to try to improve them, and, as above, encourage more use of public domain instruments) but obviously these licenses are adequate to facilitate vibrant commons projects (essentially all well known free/open source software, except for SQLite and djbware, which use public domain dedications), and it is the actual commons that needs to be favored, not some idealized zero friction symmetry between patent and copyright.

The historical reason to say “public domain” instead of “open source license” is possible legal precedent: back when software was unpatentable, it was also uncopyrightable. An awful lot of public domain software used to exist, and when people added copyrights to it, they opened it to patents as well. Software that _isn’t_ copyrighted, historically, also wasn’t patented. If somebody tries to enforce patents against public domain software, we can make a clear distinction and ask a judge to opine.

4) I’m not a lawyer, but I’d bet heavily against us winning. Happy to be wrong.

5) I’ve already mentioned size of the constituency for (2) and quantity of (3) free/open source software relative to only public domain software, but these bear repeating in the form of size of benefit. Protecting all free/open source software from patents would immediately benefit millions of free/open source software developers and users, and solve big problems for free/open source software and standards. There would be essentially no immediate benefit from only protecting public domain software from patents. Long term it would encourage more public domain software. To make that extremely lopsided trade off one has to believe that free/open source licenses are really, really awful relative to the public domain. I can understand that belief emotionally, but don’t think what evidence we have about success of various projects bears the belief out. Rather, the specific conditions (including none) just aren’t all that important so long as a minimum of permissions are granted. Exclusive public domain advocates may hate licenses, but licenses just don’t matter that much!

As the title of this post implies, free/open source software (inclusive of public domain software) is not the only commons threatened by patents that ought be favored through blanket protection from patents. Defining some of these (e.g., for seeds, 3D printing, general purpose robotics, and synthetic biology?) will be harder, in part because there may be no “well understood term in the trade” such as “open source”, but this is a much smaller hurdle (indeed, a sub-sub-task of) than organizing the relevant constituencies and making the case to the public and policymakers that favoring commons is indeed good policy.

How different would the net be without Firefox?

Sunday, April 6th, 2014

David Flanagan, latest making claim I’ve read many times:

Without Mozilla, there would have been no Firefox, and the internet would be very different today.

Mitchell Baker in only a few more words included a combined mechanism and outcome:

We moved the desktop and browsing environments to a much more open place, with far more options and control available to individuals.

Baker further explained Mozilla aims to make an analogous difference in the computing environment of today and the future:

Today we live in a different online era. This era combines desktop, mobile devices, cloud services, big data and a social layer. It is feature-rich, highly centralized, and focused on a few giant organizations that exert control over almost all aspects of the experience. Today’s computing environment is deeply in need of an open, exciting alternative that shows what the Open Web brings to this setting — something built on parts including Firefox OS, WebGL, asm.js, and the many other innovations being developed at Mozilla. It is comparable to the desktop computing environment we set out to revolutionize when we started Mozilla.

Mozilla needs to bring a similar scope of change to the new computing era. Once again, Mozilla needs to break down the walled gardens of online life and bring openness and opportunity to all. Once again, we have the chance to build products and communities in a way that no one else will.

(Baker’s post announced Brendan Eich as CEO, Flanagan lays out some information following Eich’s resignation. That crisis presumably changed nothing about evaluations of Mozilla’s previous impact, nor its plans for analogous future impact. The crisis just provided an opportunity for many to repeat such evaluations and plans. This post is my idiosyncratic exploitation of the opportunity.)

Those are important claims and plans, and I tend to strongly agree with them. My logic, in brief:

  • there’s a lot of scope for the net (and society at large) to be substantially more or less “open” than it is or might be due to relatively small knowledge policy and knowledge economy changes;
  • there’s a lot of scope for commons-based projects to push the knowledge economy (and largely as an effect, knowledge policy) in the direction of “open”;
  • due to network effects and economies of scale, huge commons-based projects are needed to realize this potential for pushing society in an “open” direction;
  • Mozilla is one of a small number of such huge commons-based projects, and its main products have and will be in positions with lots of leverage.

Independent of my logic (which of course I doubt and welcome criticism of) for agreeing with them, I think claims about Mozilla’s past and potential future impact are important enough to be criticized and refined rather than suffering the unremitting bludgeoning of obscurity or triviality.

How could one begin to evaluate how much and what sort of difference Mozilla, primarily through Firefox, has made? Some things to look at:

  • other free/open source software browser projects;
  • competition among proprietary browsers;
  • differences between Firefox and proprietary browsers in developing and implementing web standards;
  • all aspects of Mozilla performance vs. comparable (Mozilla is different in many respects, but surely amenable to many tools of organizational evaluation and comparison) organizations;
  • 2nd order effects of a superior (for a period, and competitive otherwise) free/open source browser, e.g., viability of free desktop (though never achieving significant market share, must be responsible for huge increases in consumer surplus due through constraint on proprietary pricing and behavior) and inspiration for other open source projects, demonstration of feasibility of commons-based competition in mass market.

It’s possible that such questions are inadequate for characterizing the impact of Mozilla, but surely they would help inform such characterization. If those are the wrong questions, or the wrong sort of questions, what are the right ones? Has anyone, in any field, taken evaluation of Mozilla’s differential impact beyond the Baker quote above? I’d love to read about how the net would have been different without Firefox, and how we might expect the success or failure of new Mozilla initiatives to produce different worlds.

These kinds of questions are also important (or at a minimum, interesting to me) for other commons-based initiatives, e.g., Wikimedia and Creative Commons.

Document marketing freedom 0.1

Wednesday, March 26th, 2014

Yesterday (emphasis added):

Microsoft’s DOS-based version of Word, first released in 1983, was not a success against the dominant word processor of that era, WordPerfect. The 1989 release of Word for Windows changed all that: within four years it was generating over half the worldwide word processing market revenue. It was a remarkable marketing and engineering achievement. We are today revealing the technical magic by releasing the source code to version 1.1a of Word for Windows.

Today (March 26) is Document Freedom Day, promoting open standards. I’m all for open standards, particularly as a matter of policy at all levels, and hats off to DFD for any increased awareness of the rationale for open standards and demand for open standards that result from DFD activities. But non-open formats’ domination of word processing and many other fields is not due to advocacy of closed standards, and I doubt generic advocacy of open formats will lead to the liberation of word processing or any other field.

Individuals and organizations adopt specific software. There’s lots of remarkable engineering behind specific programs which implement open standards. Remarkable marketing (broadly construed — any sales or adoption effort) of such programs? It should be no surprise that free/open products (this applies to much more than software) in almost all mass markets remain marginal — the result of failure to compete with proprietary/closed vendors on marketing (previously stated).

In my DFD post last year I called out LibreOffice and Jitsi as open standard implementing programs needing promotion. Each has made lots of engineering progress in the past year. Please let me know if I’ve missed corresponding marketing progress. (This is not a criticism of either project. I’m sure they’d each love marketing help. LibreOffice does have some community marketing efforts.)

Granted, remarkable marketing of free/open products might be as different from marketing of proprietary/closed products as engineering/provisioning of same can be different, and public policy advocacy might be a disproportionate part of remarkable free/open marketing. But lack of direct competition in the non-policy market seems to make free/open policy advocacy much harder — anyone can see when an abstract policy mandating some form of open concretely means adopting software or some other product that few people are already using (consider how much value of software and other knowledge products is driven by network effects) — a tough sell.

Producing Open Source Software (2005) gathers lots of wisdom and a 2nd edition is due this year. I suspect we’re at about 1995 for a hypothetical Marketing Open Source Software (and other open stuff) — not much wisdom to gather, and lots of doubt about whether out-marketing proprietary/closed vendors is even feasible.

“I would love it if all patents evaporated” (WebRTC)

Monday, November 11th, 2013

I’ve been following WebRTC (Real Time Communications) because (1) it is probably the most significant addition to the web in terms of enabling a new class of applications at least since the introduction of Ajax (1998, standardized by 2006), and perhaps since the introduction of Javascript (1995, standardized by 1997). The IETF working group charter puts it well (another part of the work is at W3C):

There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers’ web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients.

(See pad.textb.org (source) for one simple application; simpleWebRTC seems to be a popular library for building WebRTC applications.)

And (2) because WebRTC is the scene of the latest fight to protect open web standards from rent seekers.

The IETF working group is choosing between H.264 Constrained Baseline Profile Level 1.2 and VP8 as the Mandatory To Implement (MTI) video codec (meaning all applications can count on that codec being available) for WebRTC. H.264 cannot be included in free and open source software, VP8 can, due to their respective patent situations. (For audio-only WebRTC applications, the free Opus codec seems to be a non-controversial requirement.)

Cisco has recently promised that in 2014 they will make available a binary implementation of H.264 for which they will pay license fees for all comers (there is an annual cap on fees, allowing them to do this). That’s nice of them, but the offer is far from ideal for any software (a binary must be downloaded from Cisco servers for each user), and a nonstarter for applications without some kind of plugin system, and for free and open source software distributions, which must be able to modify source code.

Last week I remotely attended a meeting on the MTI video codec choice. No consensus was reached; discussion continues on the mailing list. One interesting thing about the non-consensus was the split between physical attendees (50% for H.264 and 30% for VP8) and remote attendees (20% for H.264, 80% for VP8). A point mentioned several times was the interest of “big players” (mostly fine with paying H.264 fees, and are using it in various other products) and “little players” (fees are significant, eg startups, or impossible, eg free and open source projects); depending on one’s perspective, the difference shows how venue biases participation in one or both directions.

Jonathan Rosenberg, the main presenter for H.264, at about 22 minutes into a recording segment:

I would love it if all patents evaporated, if all the stuff was open source in ways that we could use, and we didn’t have to deal with any of this mess.

The argument for why H.264 is the best choice for dealing with “this mess” boils down to H.264 having a longer history and broader adoption than VP8 (in other applications; the two implementation of WebRTC so far, in recent versions of Chrome and Firefox, so far exclusively use VP8).

Harald Alvestrand, the main presenter for VP8, at about 48 minutes into another recording segment:

Development of codecs has been massively hampered and held back by the fact that it has been done in a fashion that has served to maximize the patent encumbrances on codecs. Sooner or later, we should see a way forward to abandon the dependence on encumbered codecs also for video software. My question, at this juncture, is if not now, when?

Unsurprisingly, I find this (along with the unworkability of H.264 for free and open source software) a much more compelling argument. The first step toward making patents evaporate (or at least irrelevant for digital video) is to select a codec which has been developed to maximize freedom, rather than developed to maximize encumbrances and rent collection.

What are individuals and entities pushing H.264 as the best codec for now, given the mess, doing for the longer term? Are they working on H.265, in order to bake in rents for the next generation? Or are they contributing to VP9, the next-next generation Daala, and the elimination of software patents?

Addendum: Version of this post sent to rtcweb@ietf.org (and any followups).

5 fantasy Internet Archive announcements

Thursday, October 24th, 2013

Speaking of public benefit spaces on the internet, tonight the Internet Archive is having its annual celebration and announcements event. It’s a top contender for the long-term most important site on the internet. The argument for it might begin with it having many copies at many points in time of many sites, mostly accessible to the public (Google, the NSA and others must have vast dark archives), but would not end there.

I think the Internet Archive is awesome. Brewster Kahle, its founder, is too. It is clear to me that he’s the most daring and innovative founder or leader in the bay area/non-profit/open/internet field and adjacencies. And he calls himself Digital Librarian. Hear, hear!

But, the Internet Archive could be even more awesome. Here’s what I humbly wish they would announce tonight:

  • A project to release all of the code that runs their websites and all other processes, under free/open source software licenses, and do their work in public repositories, issue trackers, etc. Such crucial infrastructure ought be open to public audit, and welcoming to public contribution. Obviously much of the code is ancient, crufty, and likely has security issues. No reason for embarrassment or obscurity. The code supporting the recording of this era of human communication is itself a dark archive. Danger! Fix it.
  • WikiNurture media collections. I believe media item metadata is now unversioned. It should be versioned. And the public should be able to enhance and correct metadata. Currently media in the Internet Archive is much less useful than it could be due to poor metadata (eg I expect music I download from the archive to not have good artist/album/title tags, making it a huge pain to integrate into my listenng habits, including to tell the world and make popular) and very limited relations among media items.
  • Aggressively support new free media formats, specifically Opus and WebM right now. This is an important issue for the free and open issue, and requires collective action. Internet Archive is in a key position, and should be exploit is strong position.
  • On top of existing infrastructure and much richer data, above, build Netflix-level experiences around the highest quality media in the archive, and perhaps all media with high quality metadata. This could be left to third parties, but centralization is powerful.
  • Finally, and perhaps the deadly combination of most contentious and least exciting: stop paying DRM vendors and publishers. Old posts on this: 1, 2, 3. Internet Archive is not in the position Mozilla apparently think they are, of tolerating DRM out of fear of losing relevance. Physical libraries may think they are in such a position, but only to the extent they think of themselves as book vendors, and lack vision. Please, show leadership to the digital libraries we want in the future, not grotesque compromises, Digital Librarian!

These enhancements would elevate Internet Archive to is proper status, and mean nobody could ever again justifiably say that ‘Aside from Wikipedia, there is no large, popular space being carved out for the public good.’

Addendum: The actual announcements were great, and mostly hinted at on the event announcement post. The Wayback Machine now can instantly archive any URL (“Save Page Now”). I expect to use that all the time, replacing webcitation.org. This post pre-addendum, including many spelling errors (written on the 38 Geary…). Javascript MESS and the software archive are tons of fun: “Imagine every computer that ever existed, in your browser.” No talk of DRM, but also no talk of books, unless I missed something.

Addendum 20131110: “What happened to the Library of Alexandria?” as a lead in to explaining why the Internet Archive has multiple data centers will take on new meaning from a few days ago, when there was a fire at its scanning center (no digital records were lost). Donate.