Post Public Domain

Wikidata II

Thursday, October 30th, 2014


Wikidata went live two years ago, but the II in the title is also a reference to the first page called Wikidata on meta.wikimedia.org which for years collected ideas for first class data support in Wikipedia. I had linked to Wikidata I writing about the most prominent of those ideas, Semantic MediaWiki (SMW), which I later (8 years ago) called the most important software project and said would “turn the universal encyclopedia into the universal database while simultaneously improving the quality of the encyclopedia.”

SMW was and is very interesting and useful on some wikis, but turned out to be not revolutionary (the bigger story is wikis turned out to be not revolutionary, or only revolutionary on a small scale, except for Wikipedia) and not quite a fit for Wikipedia and its sibling projects. While I’d temper “most” and “universal” now (and should have 8 years ago), the actual Wikidata project (created by many of the same people who created SMW) is rapidly fulfilling general wikidata hopes.

One “improving the encyclopedia” hope that Wikidata will substantially deliver on over the next couple years and that I only recently realized the importance of is increasing trans-linguistic collaboration and availability of the sum of knowledge in many languages — when facts are embedded in free text, adding, correcting, and making available facts happens on a one-language-at-a-time basis. When facts about a topic are in Wikidata, they can be exposed in every language so long as labels are translated, even if on many topics nothing has ever been written about in nor translated into many languages. Reasonator is a great demonstrator.

Happy 2nd to all Wikidatians and Wikidata, by far the most important project for realizing Wikimedia’s vision. You can and should edit the data and edit and translate the schema. Browse Wikidata WikiProjects to find others working to describe topics of interest to you. I imagine some readers of this blog might be interested in WikiProjects Source MetaData (for citations) and Structured Data for Commons (the media repository).

For folks concerned about intellectual parasites, Wikidata has done the right thing — all data dedicated to the public domain with CC0.

Generative acknowledgement

Thursday, July 31st, 2014

Robin Sloan, The secret of Minecraft: And its challenge to the rest of us

In the 2010s and beyond, it is not the case that every cultural product ought to be a generative, networked system.

It is, I believe, the case that all the really important ones will be.

Nathan Matias, Designing Acknowledgement on the Web:

A system which acknowledges the beauty of cooperative relationships can’t be based on the impersonal idea of hypertext or the egocentric notion of authorship. It can’t rely on licenses to threaten people into acknowledging each other.

Via 1 2 3 and confirmation bias about which I can’t think of anything smart to say, so I’ll include a fun word: contextomy. Neither of the above reaches that bar, but I’ll try harder next time.

Posts on the ought of generative, networked production and intellectual parasite debasement of acknowledgement.

“Open policy” is the most promising copyright reform

Thursday, June 26th, 2014

Only a few days (June 30 deadline) for applications to the first Institute for Open Leadership. I don’t know anything about it other than what’s at the link, but from what I gather it involves a week-long workshop in the San Francisco area on open policy and ongoing participation in an online community of people promoting open policies in their professional capacities, and is managed by an expert in the field, Timothy Vollmer. Read an interview with Vollmer (wayback link to spare you the annoying list-gathering clickthrough at the original site, not least because its newsletter is an offender).

The institute and its parent Open Policy Network define:

Open Policy = publicly funded resources are openly licensed resources.

(Openly licensed includes public domain.)

Now, why open policy is the most promising knowledge regulation reform (I wrote “copyright” in the title, but the concept is applicable to mitigating other IP regimes, e.g., patent, and pro-commons regulation not based on mitigating IP):

  • Most proposed reforms (formalities can serve as an example for each mention following) merely reduce inefficiencies and embarrassments of freedom infringing regimes in ways that don’t favor commons-based production, as is necessary for sustainable good policy. Even if not usually conceptualized as commons-favoring, open policy is strongly biased in that direction as its mechanism is mandate of the terms used for commons-based production: open licenses. Most proposed reforms could be reshaped to be commons-favoring and thinking of how to do so a useful exercise (watch this space) but making such reshaping gain traction, as a matter of discourse let alone implementation, is a very long-term project.
  • The concept of open policy is scalable. There’s no reason as it gains credence to push for its expansion to everything receiving public or publicly interested support, including high and very low culture subsidy. At the extreme, the only way to avoid being subject to some open policy mandate would be to create restricted works in an IPer colony, isolated from the rest of humanity.
  • In order to make open policy gain much more credence than it has now, its advocates will be forced to make increasingly sophisticated public policy arguments to support claims that open policy “maximizes public investment” or to shift the object of maximization to freedom and equality. Most proposed reforms, because they would only reduce inefficiency and embarrassment, do not force much sophistication, leaving knowledge regulation discourse rotting in a trough where economists abandoned it over a century ago.
  • Open policy implementation has the potential to destroy the rents of freedom infringing industries. For sustainable good policy it is necessary to both build up the commons as an interest group and diminish interest groups that depend or think they depend on infringing freedom. It is possible for open policy to be gamed (e.g., hybrid journal double dipping). As troubling as that is, it seems to me that open policy flips which side is left desperately clawing for loopholes contrary to the rationale of policy. Most reform proposals at least implicitly take it as a given that public interest is the desperate side.
  • Open policy does not require any fundamental changes to national law or international treaties, meaning it is feasible, now. Hopefully a few reformists have generally grasped the no-brainer concept that a benefit obtained today is more valuable than one obtained in the future, e.g., in 95 years. It also doesn’t mean that open policy is merely a “patch” in contrast the “fixes” of most proposed reforms — which aren’t fixes anyway, but rather mitigations of the worst inefficiencies and embarrassments of freedom infringing regimes. If open policy is a patch, it is a one that helps the body of knowledge regulation to heal, by the mechanisms above (promoting commons production and discourse, diminishing freedom infringing interests).

In my tradition of critical cheering, consider the following Open Policy Network statement:

We have observed that current open policy efforts are decentralized, uncoordinated and insular; there is poor and/or sporadic information sharing.

As illustrated by the lack of the Open Source Definition or any software-centric organizations on Open Policy Network lists of its guiding principles and member organizations. Fortunately software is mentioned several times, for example:

If we are going to unleash the power of hundreds of billions of dollars of publicly funded education, research, data, and software, we need broad adoption of open policies.

Hopefully if the Open Policy Network is to become an important venue for moving open policy forward, people who understand software will get involved (by the way, one of the ways “publicly funded” is scalable is that it properly includes procurement, not only wholly funded new resources), e.g., FSFE and April. I know talking about software is scary — because it is powerful and unavoidable. But this makes it a necessity to include in any serious project to reform the knowledge economy and policy. Before long, everything that is not software or suffused with software will be obsolete.

{ "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?

Without Intellectual Property Day [edit]

Saturday, April 26th, 2014
Without Intellectual Property Day by Parker Higgins of the EFF is quite good, and released under CC-BY. Clearly deserving of adaptation. Mine below, followed by a diff.

April 26 is the day marked each year since 2000 by the World Intellectual Property Organization (WIPO) as “World Intellectual Property Day”, in which WIPO tries to associate its worldwide pushes for more enclosure with creativity.

Celebrating creativity is a good thing, but when you’re a hammer, everything looks like a nail. For the World Intellectual Property Organization, it may seem like creativity and “intellectual property” are inextricably linked. That’s not the case. In the spirit of adding to the conversation, let’s honor all the creativity and industry that is happening without a dependence on a system intellectual property.

There’s an important reason to encourage and promote creativity outside the bounds of increasingly restrictive laws: to the extent such creativity succeeds, it helps us re-imagine the range of desirable policy and reduces the resources available to enclosure industries to lobby for protectionism — in sum shifting what is politically possible. It’s incumbent on all of us who want to encourage creativity to continue to explore and utilize structures that reward creators without also restricting speech.

Comedy, Fashion, Cooking, Magic, and More

In the areas in which intellectual freedom is not typically infringed, there is tremendous innovation and consistent creativity outside of the intellectual property system. Chefs create new dishes, designers imagine new styles, comedians write new jokes, all without a legal enforcement mechanism to restrict others from learning and building on them.

There may be informal systems that discourage copying—the comedy community, to take one example, will call out people who are deemed to be ripping off material—but for the most part these work without expensive litigation, threats of ruinous fines, and the creation of systems of surveillance and censorship.

Contributing to a Creative Commons

The free software movement pioneered the practice of creating digital media that can legally and freely be shared and expanded, building a commons. The digital commons idea is being pushed in more areas than ever before, including culture, education, government, hardware design, and research. There are some projects we’re all familiar with — Wikipedia is perhaps the most prominent, creating an expansive and continuously updated encyclopedia that is freely accessible under permissive terms to the entire world.

Focusing on this year’s World IP Day theme of movies, there have been some impressive contributions the commons over the years. Nina Paley’s feature animation Sita Sings The Blues, which she released into the public domain, has spread widely, inspired more work, and earned her money. The short films from the Blender Foundation have demonstrated cutting-edge computer graphics made with free software and, though they’ve sometimes been on the receiving end of bogus copyright takedowns, have been watched many millions of times.

Kickstarting and Threshold Pledges

Finally, crowdfunding platforms like Kickstarter and Indie-Go-Go have made a major splash in the last few years as another fundraising model that can complement, or even replace, copyright exclusivity. These platforms build on theoretical framework laid out by scholars like John Kelsey and Bruce Schneier in the influential “Street Performer Protocol” paper, which set out to devise an alternative funding system for public domain works. But most crowdfunded works are not in the commons, indicating an need for better coordination of street patrons.

Looking at movies in particular: Kickstarter alone has enabled hundreds of millions of dollars of pledges, hundreds of theatrical releases, and seven Oscar-nominated films (including Inocente, winner of the Best Documentary Short category). Blender Foundation is currently crowdfunding its first feature length film, Gooseberry.

***

The conceit of copyright and other “intellectual property” systems is that they can be calibrated to promote the progress of science and the useful arts. But the reality of these systems is corruption and rent seeking, not calibration. The cost is not just less creativity and innovation, but less freedom and equality.

It’s clear from real world examples that other systems can achieve the goal of promoting creativity, progress, and innovation. We must continue to push for both practice and policy that favors these systems, ultimately rendering “intellectual property” a baffling anachronism. In a good future, a policy-oriented celebration of creativity and innovaion would be called World Intellectual Freedom Day.

wdiff -n eff-wipd.html eff-wipd-edit.html |colordiff |aha -w > eff-wipd-diff.html
[-<p>Today, April 26,-]{+<p>April 26+} is the day marked each year since 2000 [-as "Intellectual Property Day"-] by the <a href="https://www.eff.org/issues/wipo">World Intellectual Property Organization [-(WIPO)</a>. There are many areas where EFF has not historically agreed with WIPO,-] {+(WIPO)</a> as "World Intellectual Property Day", in+} which [-has traditionally pushed-] {+WIPO tries to associate its <a href="https://www.eff.org/deeplinks/2013/03/ustr-secret-copyright-agreements-worldwide">worldwide pushes+} for more [-restrictive agreements and served as a venue for <a href="https://www.eff.org/deeplinks/2013/03/ustr-secret-copyright-agreements-worldwide">domestic policy laundering</a>, but we agree that celebrating-] {+enclosure</a> with creativity.</p>+}
{+<p>Celebrating+} creativity is a good [-thing.</p>-]
[-<p>As the saying goes, though:-] {+thing, but+} when you're a hammer, everything looks like a nail. For the World Intellectual Property Organization, it may seem like creativity and <a href="https://www.eff.org/issues/intellectual-property/the-term">"intellectual property"</a> are inextricably linked. That's not the case. In the spirit of adding to the conversation, [-we'd like to-] {+let's+} honor all the creativity and industry that is happening <i>without</i> a dependence on a system intellectual property.</p>
<p>There's an important reason to encourage {+and promote+} creativity outside the bounds of increasingly restrictive [-laws, too. As Ninth Circuit Chief Justice Alex Kozinski eloquently explained in <a href="http://notabug.com/kozinski/whitedissent">a powerful dissent</a> some 20 years ago, pushing only for more IP restrictions tips a delicate balance against creativity:</p>-]
[-<blockquote><p>Overprotecting intellectual property is as harmful as underprotecting it. Creativity is impossible without a rich public domain. Nothing today, likely nothing since we tamed fire, is genuinely new: Culture, like science and technology, grows by accretion, each new creator building on-] {+laws: to+} the [-works-] {+extent such creativity succeeds, it helps us re-imagine the range+} of [-those who came before. Overprotection stifles the very creative forces it's supposed-] {+desirable policy <i>and</i> reduces the resources available+} to [-nurture.</p></blockquote>-]
[-<p>It's-] {+enclosure industries to lobby for protectionism -- in sum shifting what is politically possible. It's+} incumbent on all of us who want to encourage creativity to continue to explore {+and utilize+} structures that reward creators without also restricting speech.</p>
<h3>Comedy, Fashion, Cooking, Magic, and More</h3>
<p>In the areas [-known as copyright's "negative spaces,"-] {+in which intellectual freedom is not typically infringed,+} there is tremendous innovation and consistent creativity outside of the intellectual property system. Chefs create new dishes, designers imagine new styles, comedians write new jokes, all without a legal enforcement mechanism to restrict others from learning and building on them.</p>
<p>There may be informal systems that discourage copying—the comedy community, to take one example, <a href="http://www.slate.com/articles/arts/culturebox/features/2014/the_humor_code/joke_theft_can_a_comedian_sue_if_someone_steals_his_material.html">will call out people</a> who are deemed to be ripping off material—but for the most part these work without expensive litigation, threats of ruinous fines, and the creation of systems [-that can be abused to silence lawful non-infringing speech.</p>-] {+of surveillance and censorship.</p>+}
<h3>Contributing to a Creative Commons</h3>
<p>The free software movement [-may have popularized-] {+pioneered+} the [-idea-] {+practice+} of creating digital media that can legally and freely be shared and expanded, [-but the free culture movement has pushed the-] {+building a commons. The digital commons+} idea [-further-] {+is being pushed in more areas+} than ever [-before.-] {+before, including culture, education, government, hardware design, and research.+} There are some projects we're all familiar [-with—Wikipedia-] {+with -- Wikipedia+} is perhaps the most prominent, creating an expansive and continuously updated encyclopedia that is freely accessible under permissive terms to the entire world.</p>
<p>Focusing on this year's World IP Day theme of movies, there have been some impressive contributions the commons over the years. Nina Paley's feature animation <i><a href="http://www.sitasingstheblues.com/">Sita Sings The Blues</a></i>, which she released into the public domain, has spread widely, inspired more work, and earned her money. The <a href="http://www.techdirt.com/articles/20101002/20174711259/open-source-animated-movie-shows-what-can-be-done-today.shtml">short films from the Blender Foundation</a> have demonstrated cutting-edge computer graphics made with free software and, though they've sometimes been on <a href="http://www.techdirt.com/articles/20140406/07212626819/sony-youtube-take-down-sintel-blenders-open-source-creative-commons-crowdfunded-masterpiece.shtml">the receiving end of bogus copyright takedowns</a>, have been watched many millions of times.</p>
<h3>Kickstarting and Threshold Pledges</h3>
<p>Finally, crowdfunding platforms like Kickstarter and Indie-Go-Go have made a major splash in the last few years as another fundraising model that can complement, or even replace, [-traditional-] copyright exclusivity. These platforms build on theoretical framework laid out by scholars like John Kelsey and [-EFF board member-] Bruce Schneier in <a href="https://www.schneier.com/paper-street-performer.html">the influential "Street Performer Protocol" paper</a>, which set out to devise an alternative funding system for public [-works.</p>-] {+domain works. But most crowdfunded works are not in the commons, indicating an need for better <a href="http://gondwanaland.com/mlog/2013/08/10/street-patrons-missing-coordination-protocol/">coordination of street patrons</a>.</p>+}
<p>Looking at movies in particular: Kickstarter alone has <a href="https://www.kickstarter.com/blog/a-big-day-for-film">enabled hundreds of millions of dollars of pledges</a>, hundreds of theatrical releases, and seven Oscar-nominated films (including <i>Inocente</i>, winner of the Best Documentary Short category). [-Along with other-] {+Blender Foundation is currently+} crowdfunding [-sites, it has allowed the development of niche projects that might never have been possible under the traditional copyright system.&nbsp;</p>-] {+its first feature length film, <em><a href="http://gooseberry.blender.org/">Gooseberry</a></em>.</p>+}
<h3>***</h3>
[-<p>As the Constitution tells us,-]
{+<p>The conceit of+} copyright and other "intellectual property" systems [-can, when-] {+is that they can be+} calibrated [-correctly,-] {+to+} promote the progress of science and the useful arts. [-We continue to work pushing for a balanced law that would better achieve that end.</p>-]
[-<p>But it's also-] {+But the reality of these systems is corruption and rent seeking, not calibration. The cost is not just less creativity and innovation, but less freedom and <a href="http://gondwanaland.com/mlog/2014/01/30/tech-wealth-ip/">equality</a>.</p>+}
{+<p>It's+} clear from [-these-] real world examples that other systems can achieve [-that-] {+the+} goal [-as well. Promoting-] {+of promoting+} creativity, progress, and [-innovation is an incredibly valuable mission—it's good to know that it doesn't have-] {+innovation. We must continue+} to [-come through systems-] {+push for both practice and <a href="http://gondwanaland.com/mlog/2014/02/09/freedoms-commons/#regulators">policy+} that [-can-] {+favors these systems</a>, ultimately rendering "intellectual property" a baffling anachronism. In a good future, a policy-oriented celebration of creativity and innovaion would+} be [-abused to stifle valuable speech.</p>-] {+called World Intellectual Freedom Day.</p>+}

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.

Hazard Records 015

Tuesday, March 25th, 2014

Hazard Records 002 cover with no copyright notice

Barcelona-based avant/improv/appropriation/noise CD-R and now netlabel Hazard Records celebrates its 15th anniversary today (March 25). All of their releases are dedicated to the public domain (recent ones using CC0; for the trivia-oriented, note their pre-CC “no rights reserved” in the cover image above). I’ve been a dedicated listener since not long after they started uploading to the Internet Archive in 2004, 76 albums as of now, with one more each of the next four weeks coming in celebration of the anniversary. My top 4 easy listening recommendations…

Anton Ignorant – S/S Magick For Abused Speakers [HR017] (meditative noise)

Breuss Arrizabalaga Quintet – Nfamoudou-Boudougou [HR038] (free jazz)

Joan Bagés i Rubí – Miscel.lània Sonora [HR053] (avant miscellany)

XMARX – Unhazardous Songs [HR060] (rock ‘n’ ‘ropriation)

Unfortunately many Hazard Records albums on the Internet Archive don’t have embedded artist/album/title metadata in the ogg/mp3/flac downloads; this being one of the main motivations behind my wishlist for that site. But nobody downloads anymore and the Internet Archive has a passable (for now, if you’re not totally expecting uninterrupted play across pages that newer sites support) embedded player, used in this post and on the site. Listen, enjoy, and share…links.

Bonus recommendation:

Musica Veneno – Whole Lotta Love Story [HR015] (intra-label appropriation)

Happy 15 Hazardous years! I’m looking forward to the next 80 records.

RDFa initial context & one dc:

Tuesday, February 4th, 2014

One of the nice things to come out of RDFa 1.1 is its initial context — a list of vocabularies with prefixes which may be used without having to define locally. In other words, just write, e.g., property="dc:title" without having to first write prefix="dc: http://purl.org/dc/terms/".

In addition to making RDFa a lot less painful to use, the list is a good starting place for figuring out what vocabularies to use (if you must), perhaps even for non-RDFa applications — the list is machine-readable of course; I was reminded to write this post when giving feedback on a friend’s proposal to use prefix:property headers in a CSV file for a custom application, and by a recent announcement of the addition of three new predefined prefixes.

Survey data such as Linked Open Vocabularies can also help figure out what to use. Unfortunately LOV and the RDFa 1.1 initial context don’t agree 100% on prefix naming, and neither provides much in the way of guidance. I think there’s room for a highly opinionated and regularly updated guide to what vocabularies to use. I’m no expert, it probably already exists — please inform me!

dc:

The first thing I’d put in such an opinionated guide is to start one’s vocabulary search with Dublin Core. Trivial, right? But there is an under-documented subtlety which I find myself pointing out when a friend runs something like the aforementioned by me — DC means DC Terms. While it’s obvious that DC Terms is a superset of DC Elements, it’s harder to find evidence that using the former is best practice for new applications, and that the latter is not still the canonical vocabulary to start with. What I’ve gathered on this follows. I realize that the URIs for individual properties and classes, the prefixes used to abbreviate those URIs, and the documents which define (in English and RDF) properties and classes are distinct but interdependent. Prefixes are surely the most trivial and uninteresting, but for most people I imagine they’re important signals and documentation, thus I go on about them…

Namespace Policy for the Dublin Core Metadata Initiative (DCMI) (emphasis added):

The DCMI namespace URI for the collection of legacy properties that make up the Dublin Core Metadata Element Set, Version 1.1 [DCMES] is: http://purl.org/dc/elements/1.1/

Dublin Core Metadata Element Set, Version 1.1 (emphasis added):

Since 1998, when these fifteen elements entered into a standardization track, notions of best practice in the Semantic Web have evolved to include the assignment of formal domains and ranges in addition to definitions in natural language. Domains and ranges specify what kind of described resources and value resources are associated with a given property. Domains and ranges express the meanings implicit in natural-language definitions in an explicit form that is usable for the automatic processing of logical inferences. When a given property is encountered, an inferencing application may use information about the domains and ranges assigned to a property in order to make inferences about the resources described thereby.

Since January 2008, therefore, DCMI includes formal domains and ranges in the definitions of its properties. So as not to affect the conformance of existing implementations of “simple Dublin Core” in RDF, domains and ranges have not been specified for the fifteen properties of the dc: namespace (http://purl.org/dc/elements/1.1/). Rather, fifteen new properties with “names” identical to those of the Dublin Core Metadata Element Set Version 1.1 have been created in the dcterms: namespace (http://purl.org/dc/terms/). These fifteen new properties have been defined as subproperties of the corresponding properties of DCMES Version 1.1 and assigned domains and ranges as specified in the more comprehensive document “DCMI Metadata Terms” [DCTERMS].

Implementers may freely choose to use these fifteen properties either in their legacy dc: variant (e.g., http://purl.org/dc/elements/1.1/creator) or in the dcterms: variant (e.g., http://purl.org/dc/terms/creator) depending on application requirements. The RDF schemas of the DCMI namespaces describe the subproperty relation of dcterms:creator to dc:creator for use by Semantic Web-aware applications. Over time, however, implementers are encouraged to use the semantically more precise dcterms: properties, as they more fully follow emerging notions of best practice for machine-processable metadata.

The first two paragraphs explain why a new vocabulary was minted (so that the more precise definitions of properties already in DC Elements do not change the behavior of existing implementations; had only new terms and classes been added, maybe they could have been added to the DC Elements vocabulary, but maybe this is ahistoric, as many of the additional “qualified” DC Terms existed since 2000). The third paragraph explains that DC Terms should be used for new applications. Unfortunately the text informally (the prefixes aren’t used anywhere) notes the prefixes dc: and dcterms:, which I’ve found is not helpful in getting people to focus only on DC Terms.

Expressing Dublin Core metadata using the Resource Description Framework also notes the dc: and dcterms: prefixes for use in the document’s examples (which don’t ever actually use dc:).

Some of these documents have been updated slightly, but I believe their current versions are little changed from about 2008, a year after the proposal of the DC Terms refinements.

How to use DCMI Metadata as linked data uses the dc: and dcterms: prefixes and is clear about the ranges of properties of each: there is no incorrect usage of, e.g., purl.org/dc/elements/1.1/creator because it has no defined range nor domain, while purl.org/dc/terms/creator must be a non-literal, a purl.org/dc/terms/Agent. Perhaps this makes DC Terms seem scarier and partially explains the persistence of DC Elements. More likely I’d guess few know about the difference and lots of use of the DC Terms with non-literal ranges are used with literals in the wild (I might be guilty on occasion).

FAQ/DC and DCTERMS Namespaces:

It is not incorrect to continue using dc:subject and dc:title — alot of Semantic Web data still does — and since the range of those properties is unspecified, it is not actually incorrect to use (for example) dc:subject with a literal value or dc:title with a non-literal value. However, good Semantic Web practice is to use properties consistently in accordance with formal ranges, so implementers are encouraged to use the more precisely defined dcterms: properties.
Update, December 2011: It is worth noting that the Schema.org initiative is taking a pragmatic approach towards the formal ranges of their properties:

We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string. In the spirit of “some data is better than none”, we will accept this markup and do the best we can.

What constitutes “best practice” in this area is bound to evolve with implementation experience over time.

There you have people supplying literals for properties expecting non-literals. Schema.org RDF mappings do not formally condone this pragmatic approach, otherwise you’d see the likes of (addition in bold):

schema:creator a rdf:Property;
    rdfs:label "Creator"@en;
    rdfs:comment "The creator/author of this CreativeWork or UserComments. This is the same as the Author property for CreativeWork."@en;
    rdfs:domain [ a owl:Class; owl:unionOf (schema:UserComments schema:CreativeWork) ];
    rdfs:range [ a owl:Class; owl:unionOf (schema:Organization schema:Person xsd:string) ];
    rdfs:isDefinedBy ;
    rdfs:isDefinedBy ;

Also from 2011, a discussion of what prefixes to use in the RDFa initial context. Decision (Ivan Herman):

For the records: after having also discussed on yesterday’s telecom, I have made the changes on the profile files yesterday evening. The prefix set in the profile for http://purl.org/dc/terms/ is set to ‘dc’.

Read the expert input of Dan Brickley, Mikael Nilsson, and Thomas Baker. The initial context defines both dc: and dcterms: as prefixes for DC Terms, relegating DC Elements to dc11::

dc http://purl.org/dc/terms/ Dublin Core Metadata Terms DCMI Metadata Terms
dcterms http://purl.org/dc/terms/ Dublin Core Metadata Terms DCMI Metadata Terms
dc11 http://purl.org/dc/elements/1.1/ Dublin Core Metadata Element Set, Version 1.1 Dublin Core Metadata Element Set, Version 1.1

I found the above discussion on LOV’s entries for DC Terms and DC Elements, which use dcterms: and dce: prefixes respectively:

(2013-03-07) Bernard Vatant: Prefix restored to dcterms

(2013-06-17) Bernard Vatant: Although “dc” is often used as the prefix for this vocabulary, it’s also sometimes used for DC terms, so we preferred to use the less ambiguous “dce” and “dcterms” in LOV. See usage at http://prefix.cc/dc, http://prefix.cc/dce, http://prefix.cc/dcterms, and more discussion at http://bit.ly/uPuUTT.

I think the discussion instead supports using dc: and dc11: (because that’s what the RDFa initial context uses) instead. LOV doesn’t have a public source repository or issue tracker currently, but I understand it eventually will.

Now I have this grab-bag blog post to send to friends who propose using DC Elements. Please correct me if I’m wrong, and especially if a more concise (on this topic) and credible document exists, so I can send that instead; perhaps something like an opinionated guide to metadata mentioned way above.

Another topic such a guide might cover, perhaps as a coda, would be what to do if you really need to develop a new vocabulary. One thing is you really need to ask for help. The W3C now provides some infrastructure for doing this. Or, some qualified dissent from a hugely entertaining blogger called Brinxmat.

Some readers of my blog who have bizarrely read through this post, or skipped to the end, might enjoy Brinxmat’s Attribution licences for data and why you shouldn’t use them (another future issue report for LOV, which uses CC-BY?); I wrote a couple posts in the same blogversation; also a relevant upgrade exhortation.

Public domain wins copyright week!

Sunday, January 19th, 2014

public domain wins copyright weekEFF coordinated a six day copyright week, with suggested readings and actions in support of six principles, below with readings + actions count:

  • Transparency: 10 + 1 = 11
  • Building and Defending a Robust Public Domain: 16 + 0 = 16
  • Open Access: 9 + 2 = 11
  • You Bought it, You Own It: 8 + 3 = 11
  • Fair Use Rights: 14 + 1 = 15
  • Getting Copyright Right: 7 + 1 = 8

I couldn’t help but notice that the public domain “wins” by the metric of total readings + actions, perhaps indicative of relative enthusiasm and evaluation of importance by the communities EFF reaches. Good.

The apparent “loser” is getting copyright right, which I’ll also take undue satisfaction in: it’s an impoverished objective, relative to expanding and protecting intellectual freedom. Alternatively, public domain maximalism (second alternative, corresponding to the runner-up: fair use maximalism) is getting copyright right. But I acknowledge advocating “getting copyright right” (and the entire exercise of copyright week) is a fine thing to do given constraints, and its “loss” is likely due to being a more difficult writing assignment, and falling on the last day.

The latent “loser” though is the role of commons initiatives in changing the knowledge economy, thus the range of policies which can be imagined, and the resources available to support various policies. Some initiatives are mentioned, but almost exclusively as victims of costs imposed by bad policy. Daniel Mietchen’s Wikimedia and Open Access might be the reading closest to what I’d like to see a whole day dedicated to (on the seventh day of copyright week, commoners made their own freedom). Though starting with copyright-imposed costs to the project, Mietchen proceeds to describe collaboration among Wikimedians and the Open Access movement, and ends with (implied) competition:

wider exposure of Open Access materials through Wikimedia platforms may perhaps serve as an incentive for researchers to reconsider whether putting their articles behind access and reuse barriers is an appropriate approach to publishing them.

Related, because it is the domain of the most robust commons initiatives, it is too bad software was not the primary topic of several copyright week readings and actions. But even ignoring the seventh day angle, it is incredibly short-sighted to treat software as a separate category, whether for purposes of study or policy (e.g., copyright). All of the traditional subjects of copyright are now largely made with and mediated by software, but that’s just the beginning. Soon enough, they’ll all be software, or be obsolete. (In hindsight I should have noticed copyright week approaching, and urged various free/open source software initiatives to participate, and explain their policy relevance and potency.)

Back to cheering, I highly recommend at least skimming a few of the readings in each category, linked on the EFF copyright week page. Unless you follow knowledge policy writ large really closely, you’re almost certain to learn something new about policy battles that will play a large role in shaping the future of society.

To make up for the lack of copyright week “actions” recommended for building and defending a robust public domain: sign the public domain manifesto, upgrade your work to the public domain, and enjoy and share the greatest public domain film to date.