Post Creative Commons

copyleft.org

Monday, December 1st, 2014

Last month the Free Software Foundation and Software Freedom Conservancy launched copyleft.org, “a collaborative project to create and disseminate useful information, tutorial material, and new policy ideas regarding all forms of copyleft licensing.” The main feature of the project now is a 157 page tutorial on the GPL which assembles material developed over the past 10 years and a new case study. I agreed to write a first draft of material covering CC-BY-SA, the copyleft license most widely used for non-software works. My quote in the announcement: “I’m glad to bring my knowledge about the Creative Commons copyleft licenses as a contribution to improve further this excellent tutorial text, and I hope that copyleft.org as a whole can more generally become a central location to collect interesting ideas about copyleft policy.”

I tend to offer apologia to copyleft detractors and criticism to copyleft advocates, and cheer whatever improvements to copyleft licenses can be mustered (I hope to eventually write a cheery post about the recent compatibility of CC-BY-SA and the Free Art License), but I’m far more interested in copyleft licenses as prototypes for non-copyright policy.

For now, below is that first draft. It mostly stands alone, but might be merged in pieces as the tutorial is restructured to integrate material about non-GPL and non-software copyleft licenses. Your patches and total rewrites welcome!


Detailed Analysis of the Creative Commons Attribution-ShareAlike Licenses

This tutorial gives a comprehensive explanation of the most popular free-as-in-freedom copyright licenses for non-software works, the Creative Commons Attribution-ShareAlike (“CC-BY-SA”, or sometimes just “BY-SA”) – with an emphasis on the current version 4.0 (“CC-BY-SA-4.0”).

Upon completion of this part of the tutorial, readers can expect to have learned the following:

  • The history and role of copyleft licenses for non-software works.
  • The differences between the GPL and CC-BY-SA, especially with respect to copyleft policy.
  • The basic differences between CC-BY-SA versions 1.0, 2.0, 2.5, and 4.0.
  • An understanding of how CC-BY-SA-4.0 implements copyleft.
  • Where to find more resources about CC-BY-SA compliance.

FIXME this list should be more aggressive, but material is not yet present

WARNING: As of November 2014 this part is brand new, and badly needs review, referencing, expansion, error correction, and more.

Freedom as in Free Culture, Documentation, Education…

Critiques of copyright’s role in concentrating power over and making culture inaccessible have existed throughout the history of copyright. Few contemporary arguments about “copyright in the digital age” have not already been made in the 1800s or before. Though one can find the occasional ad hoc “anti-copyright”, “no rights reserved”, or pro-sharing statement accompanying a publication, use of formalized public licenses for non-software works seems to have begun only after the birth of the free software movement and of widespread internet access among elite populations.

Although they have much older antecedents, contemporary movements to create, share, and develop policy encouraging “cultural commons”, “open educational resources”, “open access scientific publication” and more, have all come of age in the last 10-15 years – after the huge impact of free software was unmistakable. Additionally, these movements have tended to emphasize access, with permissions corresponding to the four freedoms of free software and the use of fully free public licenses as good but optional.

It’s hard not to observe that it seems the free software movement arose more or less shortly after as it became desirable (due to changes in the computing industry and software becoming unambiguously subject to copyright in the United States by 1983), but non-software movements for free-as-in-freedom knowledge only arose after they became more or less inevitable, and only begrudgingly at that. Had a free culture “constructed commons” movement been successful prior to the birth of free software, the benefits to computing would have been great – consider the burdens of privileged access to proprietary culture for proprietary software through DRM and other mechanisms, toll access to computer science literature, and development of legal mechanisms and policy through pioneering trial-and-error.

Alas, counterfactual optimism does not change the present – but might embolden our visions of what freedom can be obtained and defended going forward. Copyleft policy will surely continue to be an important and controversial factor, so it’s worth exploring the current version of the most popular copyleft license intended for use with non-software works, Creative Commons Attribution-ShareAlike 4.0 International (CC-BY-SA-4.0), the focus of this tutorial.

Free Definitions

When used to filter licenses, the Free Software Definition and Open Source Definition have nearly identical results. For licenses primarily intended for non-software works, the Definition of Free Cultural Works and Open Definition similarly have identical results, both with each other and with the software definitions which they imitate. All copyleft licenses for non-software works must be “free” and “open” per these definitions.

There are various other definitions of “open access”, “open content”, and “open educational resources” which are more subject to interpretation or do not firmly require the equivalent of all four freedoms of the free software definition. While these definitions are not pertinent to circumscribing the concept of copyleft – which is about enforcing all four freedoms, for everyone. But copyleft licenses for non-software works are usually considered “open” per these other definitions, if they are considered at all.

The open access to scientific literature movement, for example, seems to have settled into advocacy for non-copyleft free licenses (CC-BY) on one hand, and acceptance of highly restrictive licenses or access without other permissions on the other. This creates practical problems: for example, nearly all scientific literature either may not be incorporated into Wikipedia (which uses CC-BY-SA) or may not incorporate material developed on Wikipedia – both of which do happen, when the licenses allow it. This tutorial is not the place to propose solutions, but let this problem be a motivator for encouraging more widespread understanding of copyleft policy.

Non-software Copylefts

Copyleft is a compelling concept, so unsurprisingly there have been many attempts to apply it to non-software works – starting with use of GPLv2 for documentation, then occasionally for other texts, and art in various media. Although the GPL was and is perfectly usable for any work subject to copyright, several factors were probably important in preventing it from being the dominant copyleft outside of software:

  • the GPL is clearly intended first as a software license, thus requiring some perspective to think of applying to non-software works;
  • the FSF’s concern is software, and the organization has not strongly advocated for using the GPL for non-software works;
  • further due to the (now previous) importance of its hardcopy publishing business and desire to retain the ability to take legal action against people who might modify its statements of opinion, FSF even developed a non-GPL copyleft license specifically for documentation, the Free Documentation License (FDL; which ceases to be free and thus is not a copyleft if its “invariant sections” and similar features are used);
  • a large cultural gap and lack of population overlap between free software and other movements has limited knowledge transfer and abetted reinvention and relearning;
  • the question of what constitutes source (“preferred form of the work for making modifications”) for many non-software works.

As a result, several copyleft licenses for non-software works were developed, even prior to the existence of Creative Commons. These include the aforementioned FDL (1998), Design Science License (1999), Open Publication License (1999; like the FDL it has non-free options), Free Art License (2000), Open Game License (2000; non-free options), EFF Open Audio License (2001), LinuxTag Green OpenMusic License (2001; non-free options) and the QING Public License (2002). Additionally several copyleft licenses intended for hardware designs were proposed starting in the late 1990s if not sooner (the GPL was then and is now also commonly used for hardware designs, as is now CC-BY-SA).1

At the end of 2002 Creative Commons launched with 11 1.0 licenses and a public domain dedication. The 11 licenses consisted of every non-mutually exclusive combination of at least one of the Attribution (BY), NoDerivatives (ND), NonCommercial (NC), and ShareAlike (SA) conditions (ND and SA are mutually exclusive; NC and ND are non-free). Three of those licenses were free (as was the public domain dedication), two of them copyleft: CC-SA-1.0 and CC-BY-SA-1.0.

Creative Commons licenses with the BY condition were more popular, so the 5 without (including CC-SA) were not included in version 2.0 of the licenses. Although CC-SA had some advocates, all who felt very strongly in favor of free-as-in-freedom, its incompatibility with CC-BY-SA (meaning had CC-SA been widely used, the copyleft pool of works would have been further fragmented) and general feeling that Creative Commons had created too many licenses led copyleft advocates who hoped to leverage Creative Commons to focus on CC-BY-SA.

Creative Commons began with a small amount of funding and notoriety, but its predecessors had almost none (FSF and EFF had both, but their entries were not major focuses of those organizations), so Creative Commons licenses (copyleft and non-copyleft, free and non-free) quickly came to dominate the non-software public licensing space. The author of the Open Publication License came to recommend using Creative Commons licenses, and the EFF declared version 2.0 of the Open Audio License compatible with CC-BY-SA and suggested using the latter. Still, at least one copyleft license for “creative” works was released after Creative Commons launched: the Against DRM License (2006), though it did not achieve wide adoption. Finally a font-specific copyleft license (SIL Open Font License) was introduced in 2005 (again the GPL, with a “font exception”, was and is now also used for fonts).

Although CC-BY-SA was used for licensing “databases” almost from its launch, and still is, copyleft licenses specifically intended to be used for databases were proposed starting from the mid-2000s. The most prominent of those is the Open Database License (ODbL; 2009). As we can see public software licenses following the subjection of software to copyright, interest in public licenses for databases followed the EU database directive mandating “sui generis database rights”, which began to be implemented in member state law starting from 1998. How CC-BY-SA versions address databases is covered below.

Aside on share-alike non-free therefore non-copylefts

Many licenses intended for use with non-software works include the “share-alike” aspect of copyleft: if adaptations are distributed, to comply with the license they must be offered under the same terms. But some (excluding those discussed above) do not grant users the equivalent of all four software freedoms. Such licenses aren’t true copylefts, as they retain a prominent exclusive property right aspect for purposes other than enforcing all four freedoms for everyone. What these licenses create are “semicommons” or mixed private property/commons regimes, as opposed to the commons created by all free licenses, and protected by copyleft licenses. One reason non-free public licenses might be common outside software, but rare for software, is that software more obviously requires ongoing maintenance.2 Without control concentrated through copyright assignment or highly asymmetric contributor license agreements, multi-contributor maintenance quickly creates an “anticommons” – e.g., nobody has adequate rights to use commercially.

These non-free share-alike licenses often aggravate freedom and copyleft advocates as the licenses sound attractive, but typically are confusing, probably do not help and perhaps stymie the cause of freedom. There is an argument that non-free licenses offer conservative artists, publishers, and others the opportunity to take baby steps, and perhaps support better policy when they realize total control is not optimal, or to eventually migrate to free licenses. Unfortunately no rigorous analysis of any of these conjectures. The best that can be done might be to promote education about and effective use of free copyleft licenses (as this tutorial aims to do) such that conjectures about the impact of non-free licenses become about as interesting as the precise terms of proprietary software EULAs – demand freedom instead.

In any case, some of these non-free share-alike licenses (also watch out for aforementioned copyleft licenses with non-free and thus non-copyleft options) include: Open Content License (1998), Free Music Public License (2001), LinuxTag Yellow, Red, and Rainbow OpenMusic Licenses (2001), Open Source Music License (2002), Creative Commons NonCommercial-ShareAlike and Attribution-NonCommercial-ShareAlike Licenses (2002), Common Good Public License (2003), and Peer Production License (2013). CC-BY-NC-SA is by far the most widespread of these, and has been versioned with the other Creative Commons licenses, through the current version 4.0 (2013).

Creative Commons Attribution-ShareAlike

The remainder of this tutorial exclusively concerns the most widespread copyleft license intended for non-software works, Creative Commons Attribution-ShareAlike(CC-BY-SA). But, there are actually many CC-BY-SA licenses – 5 versions (6 if you count version 2.1, a bugfix for a few jurisdiction “porting” mistakes), ports to 60 jurisdictions – 96 distinct CC-BY-SA licenses in total. After describing CC-BY-SA and how it differs from the GPL at a high level, we’ll have an overview of the various CC-BY-SA licenses, then a section-by-section walkthrough of the most current and most clear of them – CC-BY-SA-4.0.

CC-BY-SA allows anyone to share and adapt licensed material, for any purpose, subject to providing credit and releasing adaptations under the same terms. The preceding sentence is a severe abridgement of the “human readable” license summary or “deed” provided by Creative Commons at the canonical URL for one of the CC-BY-SA licenses – the actual license or “legalcode” is a click away. But this abridgement, and the longer the summary provided by Creative Commons are accurate in that they convey CC-BY-SA is a free, copyleft license.

GPL and CC-BY-SA differences

FIXME this section ought refernence GPL portion of tutorial extensively

There are several differences between the GPL and CC-BY-SA that are particularly pertinent to their analysis as copyleft licenses.

The most obvious such difference is that CC-BY-SA does not require offering works in source form, that is their preferred form for making modifications. Thus CC-BY-SA makes a huge tradeoff relative to the GPL – CC-BY-SA dispenses with a whole class of compliance questions which are more ambiguous for some creative works than they are for most software – but in so doing it can be seen as a much weaker copyleft.

Copyleft is sometimes described as a “hack” or “judo move” on copyright, but the GPL makes two moves, though it can be hard to notice they are conceptually different moves, without the contrast provided by a license like CC-BY-SA, which only substantially makes one move. The first move is to neutralize copyright restrictions – adaptations, like the originally licensed work, will effectively not be private property (of course they are subject to copyright, but nobody can exercise that copyright to prevent others’ use). If copyright is a privatized regulatory system (it is), the first move is deregulatory. The second move is regulatory – the GPL requires offer of source form, a requirement that would not hold if copyright disappeared, absent a different regulatory regime which mandated source revelation (one can imagine such a regime on either “pragmatic” grounds, e.g., in the interest of consumer protection, or on the grounds of enforcing software freedom as a universal human right).

FIXME analysis of differences in copyleft scope (eg interplay of derivative works, modified copies, collections, aggregations, containers) would be good here but might be difficult to avoid novel research

CC-BY-SA makes the first move3 but adds the second in a limited fashion. It does not require offer of preferred form for modification nor any variation thereof (e.g., the FDL requires access to a “transparent copy”). CC-BY-SA does prohibit distribution with “effective technical measures” (i.e., digital restrictions management or DRM) if doing so limits the freedoms granted by the license. We can see that this is regulatory because absent copyright and any regime specifically limiting DRM, such distribution would be perfectly legal. Note the GPL does not prohibit distribution with DRM, although its source requirement makes DRM superfluous, and somewhat analogously, of course GPLv3 carefully regulates distribution of GPL’d software with locked-down devices – to put it simply, it requires keys rather than prohibiting locks. Occasionally a freedom advocate will question whether CC-BY-SA’s DRM prohibition makes CC-BY-SA a non-free license. Few if any questioners come down on the side of CC-BY-SA being non-free, perhaps for two reasons: first, overwhelming dislike of DRM, thus granting the possibility that CC-BY-SA’s approach could be appropriate for a license largely used for cultural works; second, the DRM prohibition in CC-BY-SA (and all CC licenses) seems to be mainly expressive – there are no known enforcements, despite the ubiquity of DRM in games, apps, and media which utilize assets under various CC licenses.

Another obvious difference between the GPL and CC-BY-SA is that the former is primarily intended to be used for software, and the latter for cultural works (and, with version 4.0, databases). Although those are the overwhelming majority of uses of each license, there are areas in which both are used, e.g., for hardware design and interactive cultural works, where there is not a dominant copyleft practice or the line between software and non-software is not absolutely clear.

This brings us to the third obvious difference, and provides a reason to mitigate it: the GPL and CC-BY-SA are not compatible, and have slightly different compatibility mechanisms. One cannot mix GPL and CC-BY-SA works in a way that creates a derivative work and comply with either of them. This could change – CC-BY-SA-4.0 introduced4 the possibility of Creative Commons declaring CC-BY-SA-4.0 one-way (as a donor) compatible with another copyleft license – the GPL is obvious candidate for such compatibility. Discussion is expected to begin in late 2014, with a decision sometime in 2015. If this one-way compatibility were to be enacted, one could create an adaptation of a CC-BY-SA work and release the adaptation under the GPL, but not vice-versa – which makes sense given that the GPL is the stronger copyleft.

The GPL has no externally declared compatibility with other licenses mechanism (and note no action from the FSF would be required for CC-BY-SA-4.0 to be made one-way compatible with the GPL). The GPL’s compatibility mechanism for later versions of itself differs from CC-BY-SA’s in two ways: the GPL’s is optional, and allows for use of the licensed work and adaptations under later versions; CC-BY-SA’s is non-optional, but only allows for adaptations under later versions.

Fourth, using slightly different language, the GPL and CC-BY-SA’s coverage of copyright and similar restrictions should be identical for all intents and purposes (GPL explicitly notes “semiconductor mask rights” and CC-BY-SA-4.0 “database rights” but neither excludes any copyright-like restrictions). But on patents, the licenses are rather different. CC-BY-SA-4.0 explicitly does not grant any patent license, while previous versions were silent. GPLv3 has an explicit patent license, while GPLv2’s patent license is implied (see [gpl-implied-patent-grant] and [GPLv3-drm] for details). This difference ought give serious pause to anyone considering use of CC-BY-SA for works potentially subject to patents, especially any potential licensee if CC-BY-SA licensor holds such patents. Fortunately Creative Commons has always strongly advised against using any of its licenses for software, and that advice is usually heeded; but in the space of hardware designs Creative Commons has been silent, and unfortunately from a copyleft (i.e., use mechanisms at disposal to enforce user freedom) perspective, CC-BY-SA is commonly used (all the more reason to enable one-way compatibility, allowing such projects to migrate to the stronger copyleft).

The final obvious difference pertinent to copyleft policy between the GPL and CC-BY-SA is purpose. The GPL’s preamble makes it clear its goal is to guarantee software freedom for all users, and even without the preamble, it is clear that this is the Free Software Foundation’s driving goal. CC-BY-SA (and other CC licenses) state no purpose, and (depending on version) are preceded with a disclaimer and neutral “considerations for” licensors and licensees to think about (the CC0 public domain dedication is somewhat of an exception; it does have a statement of purpose, but even that has more of a feel of expressing yes-I-really-mean-to-do-this than a social mission). Creative Commons has always included elements of merely offering copyright holders additional choices and of purposefully creating a commons. While CC-BY-SA (and initially CC-SA) were just among the 11 non-mutually exclusive combinations of “BY”, “NC”, “ND”, and “SA”, freedom advocates quickly adopted CC-BY-SA as “the” copyleft for non-software works (surpassing previously existing non-software copylefts mentioned above). Creative Commons has at times recognized the special role of CC-BY-SA among its licenses, e.g., in a statement of intent regarding the license made in order to assure Wikimedians considering changing their default license from the FDL to CC-BY-SA that the latter, including its steward, was acceptably aligned with the Wikimedia movement (itself probably more directly aligned with software freedom than any other major non-software commons).

FIXME possibly explain why purpose might be relevant, eg copyleft instrument as totemic expression, norm-setting, idea-spreading

FIXME possibly mention that CC-BY-SA license text is free (CC0)

There are numerous other differences between the GPL and CC-BY-SA that are not particularly interesting for copyleft policy, such as the exact form of attribution and notice, and how license translations are handled. Many of these have changed over the course of CC-BY-SA versioning.

CC-BY-SA versions

FIXME section ought explain jurisdiction ports

This section gives a brief overview of changes across the main versions (1.0, 2.0, 2.5, 3.0, and 4.0) of CC-BY-SA, again focused on changes pertinent to copyleft policy. Creative Commons maintains a page detailing all significant changes across versions of all of its CC-BY* licenses, in many cases linking to detailed discussion of individual changes.

As of late 2014, versions 2.0 (the one called “Generic”; there are also 18 jurisdiction ports) and 3.0 (called “Unported”; there are also 39 ports) are by far the most widely used. 2.0 solely because it is the only version that the proprietary web image publishing service Flickr has ever supported. It hosts 27 million CC-BY-SA-2.0 photos 5 and remains the go-to general source for free images (though it may eventually be supplanted by Wikimedia Commons, some new proprietary service, or a federation of free image sharing sites, perhaps powered by GNU MediaGlobin). 3.0 both because it was the current version far longer (2007-2013) than any other and because it has been adopted as the default license for most Wikimedia projects.

However apart from the brief notes on each version, we will focus on 4.0 for a section-by-section walkthrough in the next section, as 4.0 is improved in several ways, including understandability, and should eventually become the most widespread version, both because 4.0 is intended to remain the current version for the indefinite and long future, and it would be reasonable to predict that Wikimedia projects will make CC-BY-SA-4.0 their default license in 2015 or 2016.

FIXME subsections might not be the right strcuture or formatting here

1.0 (2002-12-16)

CC-BY-SA-1.0 set the expectation for future versions. But the most notable copyleft policy feature (apart from the high level differences with GPLv2, such as not requiring source) was no measure for compatibility with future versions (nor with the CC-SA-1.0, also a copyleft license, nor with pre-existing copyleft licenses such as GPL, FDL, FAL, and others, nor with CC jurisdiction ports, of which there were 3 for 1.0).

2.0 (2004-05-25)

CC-BY-SA-2.0 made itself compatible with future versions and CC jurisdiction ports of the same version. Creative Commons did not version CC-SA, leaving CC-BY-SA-2.0 as “the” CC copyleft license. CC-BY-SA-2.0 also adds the only clarification of what constitutes a derivative work, making “synchronization of the Work in timed-relation with a moving image” subject to copyleft.

2.5 (2005-06-09)

CC-BY-SA-2.5 makes only one change, to allow licensor to designate another party to receive attribution. This does not seem interesting for copyleft policy, but the context of the change is: it was promoted by the desire to make attribution of mass collaborations easy (and on the other end of the spectrum, to make it possible to clearly require giving attribution to a publisher, e.g., of a journal). There was a brief experiment in branding CC-BY-SA-2.5 as the “CC-wiki” license. This was an early step toward Wikimedia adopting CC-BY-SA-3.0, four years later.

3.0 (2007-02-23)

CC-BY-SA-3.0 introduced a mechanism for externally declaring bilateral compatibility with other licenses. This mechanism to date has not been used for CC-BY-SA-3.0, in part because another way was found for Wikimedia projects to change their default license from FDL to CC-BY-SA: the Free Software Foundation released FDL 1.3, which gave a time-bound permission for mass collaboration sites to migrate to CC-BY-SA. While not particularly pertinent to copyleft policy, it’s worth noting for anyone wishing to study old versions in depth that 3.0 is the first version to substantially alter the text of most of the license, motivated largely by making the text use less U.S.-centric legal language. The 3.0 text is also considerably longer than previous versions.

4.0 (2013-11-25)

CC-BY-SA-4.0 added to 3.0’s external compatibility declaration mechanism by allowing one-way compatibility. After release of CC-BY-SA-4.0 bilateral compatibility was reached with FAL-1.3. As previously mentioned, one-way compatibility with GPLv3 will soon be discussed.

4.0 also made a subtle change in that an adaptation may be considered to be licensed solely under the adapter’s license (currently CC-BY-SA-4.0 or FAL-1.3, in the future potentially GPLv3 or or a hypothetical CC-BY-SA-5.0). In previous versions licenses were deemed to “stack” – if a work under CC-BY-SA-2.0 were adapted and released under CC-BY-SA-3.0, users of the adaptation would need to comply with both licenses. In practice this is an academic distinction, as compliance with any compatible license would tend to mean compliance with the original license. But for a licensee using a large number of works that wished to be extremely rigorous, this would be a large burden, for it would mean understanding every license (including those of jurisdiction ports not in English) in detail.

The new version is also an even more complete rewrite of 3.0 than 3.0 was of previous versions, completing the “internationalization” of the license, and actually decreasing in length and increasing in readability.

Additionally, 4.0 consistently treats database (licensing them like other copyright-like rights) and moral rights (waiving them to the extent necessary to exercise granted freedoms) – in previous versions some jurisdiction ports treated these differently – and tentatively eliminates the need for jurisdiction ports. Official linguistic translations are underway (Finnish is the first completed) and no legal ports are planned for.

4.0 is the first version to explicitly exclude a patent (and less problematically, trademark) license. It also adds two features akin to those found in GPLv3: waiver of any right licensor may have to enforce anti-circumvention if DRM is applied to the work, and reinstatement of rights after termination if non-compliance corrected within 30 days.

Finally, 4.0 streamlines the attribution requirement, possibly of some advantage to massive long-term collaborations which historically have found copyleft licenses a good fit.

The 4.0 versioning process was much more extensively researched, public, and documented than previous CC-BY-SA versionings; see https://wiki.creativecommons.org/4.0 for the record and https://wiki.creativecommons.org/Version_4 for a summary of final decisions.

CC-BY-SA-4.0 International section-by-section

FIXME arguably this section ought be the substance of the tutorial, but is very thin and weak now

FIXME formatted/section-referenced copy of license should be added to license-texts.tex and referenced throughout

The best course of action at this juncture would be to read http://creativecommons.org/licenses/by-sa/4.0/legalcode – the entire text is fairly easy to read, and should be quickly understood if one has the benefit of study of other public licenses and of copyleft policy.

The following walk-through will simply call out portions of each section one may wish to study especially closely due to their pertinence to copyleft policy issues mentioned above.

FIXME subsections might not be the right structure or formatting here

1 – Definitions

The first three definitions – “Adapted Material”, “Adapter’s License”, and “BY-SA Compatible License” are crucial to understanding copyleft scope and compatibility.

2 – Scope

The license grant is what makes all four freedoms available to licensees. This section is also where waiver of DRM anti-circumvention is to be found, also patent and trademark exclusions.

3 – License Conditions

This section contains the details of the attribution and share-alike requirements; the latter read closely with aforementioned definitions describe the copyleft aspect of CC-BY-SA-4.0.

4 – Sui Generis Database Rights

This section describes how the previous grant and condition sections apply in the case of a database subject to sui generis database rights. This is an opportunity to go down a rabbit-hole of trying to understand sui generis database rights. Generally, this is a pointless exercise. You can comply with the license in the same way you would if the work were subject only to copyright – and determining whether a database is subject to copyright and/or sui generis database rights is another pit of futility. You can license databases under CC-BY-SA-4.0 and use databases subject to the same license as if they were any other sort of work.

5 – Disclaimer of Warranties and Limitation of Liability

Unsurprisingly, this section does its best to serve as an “absolute disclaimer and waiver of all liability.”

6 – Term and Termination

This section is similar to GPLv3, but without special provision for cases in which the licensor wishes to terminate even cured violations.

7 – Other Terms and Conditions

Though it uses different language, like the GPL, CC-BY-SA-4.0 does not allow additional restrictions not contained in the license. Unlike the GPL, CC-BY-SA-4.0 does not have an explicit additional permissions framework, although effectively a licensor can offer any other terms if they are the sole copyright holder (the license is non-exclusive), including the sorts of permissions that would be structured as additional permissions with the GPL. Creative Commons has sometimes called offering of separate terms (whether additional permissions or “proprietary relicensing”) the confusing name “CC+”; however where this is encountered at all it is usually in conjunction with one of the non-free CC licenses. Perhaps CC-BY-SA is not a strong enough copyleft to sometimes require additional permissions, or be used to gain commercially valuable asymmetric rights, in contrast with the GPL.

8 – Interpretation

Nothing surprising here. Note that CC-BY-SA does not “reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.” This is a point that Creative Commons has always been eager to make about all of its licenses. GPLv3 also “acknowledges your rights of fair use or other equivalent”. This may be a wise strategy, but should not be viewed as mandatory for any copyleft license – indeed, the ODbL attempts (somewhat self-contradictorily; it also acknowledges fair use or other rights to use) make its conditions apply even for works potentially subject to neither copyright nor sui generis database rights.

Enforcement

There are only a small number of court cases involving any Creative Commons license. Creative Commons lists these and some related cases at https://wiki.creativecommons.org/Case_Law.

Only two of those cases concern enforcing the terms of a CC-BY-SA license (Gerlach v. DVU in Germany, and No. 71036 N. v. Newspaper in a private Rabbinical tribunal) each hinged on attribution, not share-alike.

Further research could uncover out of compliance uses being brought into compliance without lawsuit, however no such research, nor any hub for conducting such compliance work, is known. Editors of Wikimedia Commons document some external uses of Commons-hosted media, including whether user are compliant with the relevant license for the media (often CC-BY-SA), resulting in a category listing non-compliant uses (which seem to almost exclusively concern attribution).

Compliance Resources

FIXME this section is just a stub; ideally there would also be an additional section or chapter on CC-BY-SA compliance

Creative Commons has a page on ShareAlike interpretation as well as an extensive Frequently Asked Questions for licensees which addresses compliance with the attribution condition.

English Wikipedia’s and Wikimedia Commons’ pages on using material outside of Wikimedia projects provide valuable information, as the majority of material on those sites is CC-BY-SA licensed, and their practices are high-profile.

FIXME there is no section on business use of CC-BY-SA; there probably ought to be as there is one for GPL, though there’d be much less to put.

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.

wiki↔journal

Thursday, October 2nd, 2014

The first wiki[pedia]2journal article has been published: Dengue fever Wikipedia article, peer-reviewed version (PDF). Modern medicine comes online: How putting Wikipedia articles through a medical journal’s traditional process can put free, reliable information into as many hands as possible is the accompanying editorial (emphasis added):

As a source of clinical information, how does Wikipedia differ from UpToDate or, for that matter, a textbook or scholarly journal? Wikipedia lacks three main things. First, a single responsible author, typically with a recognized academic affiliation, who acts as guarantor of the integrity of the work. Second, the careful eye of a trained editorial team, attuned to publication ethics, who ensure consistency and accuracy through the many iterations of an article from submission to publication. Third, formal peer review by at least one, and often many, experts who point out conflicts, errors, redundancies, or gaps. These form an accepted ground from which publication decisions can be made with confidence.

In this issue of Open Medicine, we are pleased to publish the first formally peer-reviewed and edited Wikipedia article. The clinical topic is dengue fever. It has been submitted by the author who has made the most changes, and who has designated 3 others who contributed most meaningfully. It has been peer reviewed by international experts in infectious disease, and by a series of editors at Open Medicine. It has been copy-edited and proofread; once published, it will be indexed in MEDLINE. Although by the time this editorial is read the Wikipedia article will have changed many times, there will be a link on the Wikipedia page that can take the viewer back to the peer-reviewed and published piece on the Open Medicine website. In a year’s time, the most responsible author will submit the changed piece to an indexed journal, so it can move through the same editorial process and continue to function as a valid, reliable, and evolving free and complete reference for everyone in the world. Although there may be a need for shorter, more focused clinical articles published elsewhere as this one expands, it is anticipated that the Wikipedia page on dengue will be a reference against which all others can be compared. While it might be decades before we see an end to dengue, perhaps the time and money saved on exhaustive, expensive, and redundant searches about what yet needs to be done will let us see that end sooner.

I love that this is taking Wikipedia and commons-based peer production into a challenging product area, which if wildly successful, could directly challenge and ultimately destroy the proprietary competition. The editorial notes:

Some institutions pay UpToDate hundreds of thousands of dollars per year for that sense of security. This has allowed Wolters Kluwer, the owners of UpToDate, to accrue annual revenues of hundreds of millions of dollars and to forecast continued double-digit growth as “market conditions for print journals and books … remain soft.”

See the WikiProject Medicine collaborative publication page for more background on the process and future developments. Note at least 7 articles have been published in journal2wiki[pedia] fashion, see PLOS Computational Biology and corresponding Wikipedia articles. Ideally these 2 methods would converge on wiki↔journal, as the emphasized portion of the quote above seems to indicate.

Peer review of Wikipedia articles and publication in another venue in theory could minimize dependencies and maximize mutual benefit between expert authoring (which has historically failed in the wiki context, see Nupedia and Citizendium) and mass collaboration (see challenges noted by editorial above). But one such article only demonstrates the concept; we’ll see whether it becomes an important method, let alone market dominating one.


One small but embarrassing obstacle to wiki↔journal is license incompatibility. PLOS journals use CC-BY-4.0 (donor-only relative to following; the version isn’t important for this one) and Wikipedia CC-BY-SA-3.0 (recipient-only relative to previous…and following) and Open Medicine CC-BY-SA-2.5-Canada (donor-only relative to the immediately previous) — meaning if all contributors to the Dengue fever Wikipedia article did not sign off, the journal version is technically not in compliance with the upstream license. Clearly nobody should care about this second issue, except for license stewards, who should mitigate the problem going forward: all previous versions (2.0 or greater due to lack of a “later versions” provision in 1.0) of CC-BY-SA should be added to CC-BY-SA-4.0’s compatibility list, allowing contributions to go both ways. The first issue unfortunately cannot be addressed within the framework of current licenses (bidirectional use could be avoided, or contributors could all sign off, either of which would be outside the license framework).

Daniel Mietchen (who is a contributor to the aforementioned journal2wiki effort, and just about everything else relating to Wikipedia and Open Access) has another version of his proposal to open up research funding proposals up at the Knight News Challenge: Libraries site. Applaud and comment there if you like, as I do (endorsement of previous version).

Near the beginning of the above editorial:

New evidence pours in to the tune of 12 systematic reviews per day, and accumulating the information and then deciding how to incorporate it into one’s practice is an almost impossible task. A study published in BMJ showed that if one hoped to take account of all that has been published in the relatively small discipline of echocardiography, it would take 5 years of constant reading—by which point the reader would be a year behind.

A similar avalanche of publishing can be found in any academic discipline. It is conceivable that copyright helps, providing an incentive for services like UpToDate. My guess is that it gets in the way, both by propping up arrangements oriented toward pumping out individual articles, and by putting up barriers (the public license incompatibility mentioned above is inconsequential compared to the paywalled, umitigated copyright, and/or PDF-only case which dominates) to collaborative — human and machine — distillation of the states of the art. As I wrote about entertainment, do not pay copyright holders, for a good future.

Proprietary profitability as a key metric for open access and open source

Thursday, August 7th, 2014

Glyn Moody in Beyond Open Standards and Open Access:

Like open source, open access is definitely winning, even if there is some desperate rearguard action by the publishers, who are trying to protect their astonishing profit margins – typically 30-40%.

No doubt open source and open access have progressed, but the competition maintaining astonishing profit margins contradicts “definitely winning.” For publishing, see Elsevier, £0.8b profit on £2.1b revenue, and others. For software most pertinent to Moody’s post (concerning Open Document Format), see Microsoft’s business division, $16b profit on $24b revenue.

These profits coupled with the slow relative progress of open source and open access give proprietary vendors huge range to not only take “desperate rearguard action” but also to create new products and forms of lock-in with which the commons is continually playing catch-up.

We know what the commons “definitely winning” looks like — Linux (server software) and Wikipedia (encyclopedias) — and it includes proprietary vendor profit margins being crushed, most going out of business, and those remaining transitioning to service lines of business less predicated on privatized censorship.

When libraries begin mass cancellation of toll access journal subscriptions and organizations of all sorts cancel Microsoft, Adobe, and similar software subscriptions, then we can consider whether open access and open source are definitely winning. Until then the answer is definitely no.

As for what’s next for open standards and open access (Moody suggests further ODF mandates, which would be fine), the obvious answer is open source. It’s what allows realization of the promise of open standards, and the cancellation of Microsoft subscriptions. It’s also what’s next for academic publishing and everything else — what is not software will be obsolete — though cancellation of those toll access subscriptions is going to require going back to basics.

Free/open/commons advocates should consider destruction of proprietary competition profitability a key aim and metric of success or lack thereof, for both open products and policy. This metric has several benefits:

  • Indicates relative progress. Any non-moribund project/movement can make seeming progress, blind to different and potentially much greater progress by competition.
  • Implicates role of knowledge economy and policy in increasing or decreasing equality (of income and wealth, not just access).
  • Hard numbers, data readily available.
  • It’s reasonable to multiply destruction of proprietary profits when characterizing gains (so as to include decrease in deadweight loss).

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.

Edit Oakland wiki events

Wednesday, July 9th, 2014

Saturday, July 12, there’s a big open streets event in my obscure flats neighborhood where Oakland, Emeryville, and Berkeley meet. A small stretch of San Pablo Avenue will be closed to cars (sadly not only human-driven cars, which would momentarily meet my suggestion). E’ville Eye has a comprehensive post about the event and its origins.

There will be an Oakland Urban Paths walk in the neighborhood during the event, during which obscurities will be related. Usually these walks are in locations with more obvious scenery (hills/stairs) and historical landmarks; I’m looking forward to seeing how they address Golden Gate. Last month they walked between West Oakland and downtown, a historic and potentially beautiful route that currently crosses 980 twice — edit it out!

Monday, July 14 18:00-19:30 there’s a follow-on event at the Golden Gate Branch Library — an OaklandWiki edit party. I haven’t edited Oakland Wiki much yet, but I like the concept. It is one of many LocalWikis, which relative to MediaWiki and Wikipedia have very few features or rules. This ought greatly lower the barrier to many more people contributing information pertinent to their local situation; perhaps someone is researching that? I’ve used the OaklandWiki to look up sources for Wikipedia articles related to Oakland and have noticed several free images uploaded to OaklandWiki that would be useful on Wikipedia.

Saturday, July 19 11:00-16:00 there’s a Wikipedia edit event at Impact Hub in Oakland and online: WikiProject Open Barn Raising 2014 which aims to improve Wikipedia articles about open education — a very broad and somewhat recursive (Wikipedia is an “open educational resource”, though singular doesn’t do it justice, unless perhaps made singular the open educational resource, but that would be an overstatement). If you’re interested in OER, Open Access, open policy and related tools and organizations, or would like to learn about those things and about editing Wikipedia, please participate!

Tangentially, OpenHatch (my endorsement) got a nice writeup of its Open Source Comes to Campus events at WIRED. I view these as conceptually similar to introduction to Wiki[pedia] editing events — all aim to create a welcoming space for newcomers to dive into participating in commons-based peer production — good for learning, careers, communities, and society.

“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?

LWN.net original articles now BY-SA after a week

Thursday, May 1st, 2014

LWN.net started in 1998 as Linux Weekly News. Its coverage is broader now — Free/Open Source Software, and sometimes immediate neighbors, with in-depth coverage of Linux kernel and related system software development — and expert. It’s one of the few publications that I can read an article about a topic that I have in depth knowledge of and not then question whether all reporting on topics I don’t have in depth knowledge of is also that bad. Because LWN.net’s reporting is good (other readers I know seem to agree). LWN.net’s logo says “Linux info from the source”; I suspect the method implied (reading source, commits, mailing lists, talking to developers) explains the goodness.

I’ve poked fun at paywalls, but for a paywall, LWN.net’s is simple and well done: most new articles are subscriber-only for one week, and subscribers can generate a link to share a paywalled article with non-subscribers. The site does have ads, though disappointingly mostly Google AdSense. It is too bad such an in-depth industry publication doesn’t attract highly specific ads, like trade publications or even well done user group newsletters used to.

It seems that starting recently LWN.net releases its original articles under the CC-BY-SA-4.0 license after one week. As of this writing a week old article, a current article, another of more general interest, archive of author guidelines timestamped February 10 mentioning “possibly under a free license”, and today mentioning CC-BY-SA-4.0. I imagine that given LWN.net’s in-depth reporting, especially on the Linux kernel, some articles might actually be usefully incorporated into educational material, documentation, Wikipedia articles.

Subscribe, or occasionally read articles older than one week. Either would probably be good for your information diet.

Update 20140507: The ‘current’ articles above are now a week old, and CC-BY-SA-4.0 licensed.