Post Open Source

Friends of Software Freedom, Conservationists, Rangers: Support!

Wednesday, December 3rd, 2014

Software Freedom Conservancy, a nonprofit I serve on the board of, today announced a supporter program.

There’s plenty of info at the previous links, so I’ll just add four notes:

  1. Since Karen Sandler started as executive director earlier this year, Conservancy has been doing especially great work for its member projects (and some exciting new ones will be coming on board in the next months; if you lead a free software project, look at info on becoming a member) and is becoming even more the thought leader in both reactionary and progressive (I’m not using those terms to mark ideology here) strategies for software freedom (the italicized modifiers are there because Conservancy was already doing great work, and Sandler had been involved from the very beginning has a volunteer).
  2. Conservancy’s free software non-profit accounting project did not meet its funding goal last year, so progress this year has been slow. It’s still an important project and a successful supporters program will help free up and add resources to move it forward.
  3. Because this is the time of year end appeals (I’ll probably mention a few others in passing shortly), it’s worth noting that Bradley Kuhn (Conservancy’s president and distinguished technologist, but this is one of his many volunteer efforts) is the primary maintainer of a repository of tax filings and other data for free/open organizations. Most of this information can be found somewhere on the web, but not conveniently. Patches welcome (I’d enjoy a dedicated website, and worldwide coverage). Conservancy itself has a page with its filings and a couple explanatory posts.
  4. Didn’t I just a few days ago promote a sort of meta service for free/libre/open projects, Snowdrift.coop? Yes, but it and Conservancy are rather different on multiple dimensions. Snowdrift.coop is a crazy speculative crowdfunding platform. Conservancy is a fiscal sponsor (plus), an old and well understood model that emphasizes administration and stewardship rather than (confusingly to many people, given “fiscal” and “sponsor”) fundraising. Conservancy is able to process donations for member projects (taking a very reasonable 10% cut). If Snowdrift.coop were to become a well-established mechanism for collecting donations to free/libre/open projects such that Conservancy member projects demanded to use the Snowdrift.coop mechanism, I imagine it would be natural for Conservancy to process such funds for its projects. But, this is speculative.

Christopher Allan Webber also says that donating to Conservancy is a real bang for your buck.

Posted in Commons, Open Source, Politics | 5 Comments »

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 the free software movement arose more or less shortly after it became desirable due to changes in the computing industry, especially as software became unambiguously subject to copyright in the United States by 1983. Interestingly, similar developments are visible in other industries, such as the rise of gambling sites not on gamstop in response to regulatory shifts, offering users alternative platforms with more autonomy and fewer restrictions. Had a free culture “constructed commons” movement succeeded prior to the birth of free software, the benefits to computing could have been significant—imagine the burdens avoided from restrictive access to proprietary culture through DRM and toll access to computer science literature, or the evolution of legal mechanisms and policies developed 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 exists. 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.

  1. See https://gondwanaland.com/mlog/2012/01/10/open-hardware-licenses-history/.↩
  2. For a slightly longer version of this argument, see Free Culture in Relation to Software Freedom.↩
  3. See https://wiki.creativecommons.org/ShareAlike_interpretation.↩
  4. https://wiki.creativecommons.org/ShareAlike_compatibility↩
  5. As of November 2014. See https://www.flickr.com/creativecommons/ for counts.↩

Posted in Books, Commons, Creative Commons, DRM, Economics, Open Access, Open Hardware, Open Source, Patents, Wikipedia | 6 Comments »

Snowdrift

Sunday, November 30th, 2014

Co-founders David Thomas and Aaron Wolf (the Woz and Jobs of the project) have been working on Snowdrift.coop for at least 2 years (project announcement thread). I’ve been following their progress since, and occasionally offered advice (including on the linked thread).

Snowdrift is crowdfunding platform for ongoing (as opposed to one-off) funding, with scaled (as opposed to thresholded or unqualified) contributions, exclusively for free/open/libre (as opposed to unconditioned, mostly non-open) outputs. These features raise my interest:

  • I’ve been eager to see more nuanced crowdfunding arrangements tried since before relatively simple one-off threshold systems became popular — probably in part due to their simplicity. Snowdrift’s mechanism is both interesting, and has been criticized (see linked thread) for its complexity. It’ll be fun to see it tried out, and simplified, or even made more complex, as warranted.
  • If Snowdrift were to become a dominant platform for funding free/libre/open projects, scaling (contributors increase their contributions as more people contribute) could help create clear winners among the proliferation of such projects.
  • Today’s crowdfunding platforms were influenced (by now, mostly indirectly) by Kelsey and Schneier’s “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.

Snowdrift has additional interesting features, including organization as a cooperative, an honor code that goes beyond free/libre/open requirements, and being developed in the programming language Haskell. I’ve barely mentioned these things in the past, but they’re all interesting — alternative institutional arrangements, post-software-freedom, safety. The Snowdrift wiki has pages covering many of these topics and more in depth. They’ve also generally chosen to develop an integrated platform rather than to use existing software (e.g., for wiki, discussion, issues, mailing list) except for revision control hosting. Clearly Snowdrift is not trying to innovate in only one dimension.

Now, Snowdrift is doing a “traditional” one-off crowdfunding drive in order to get itself to production, such that the project and other free/libre/open projects can be funded on an ongoing fashion using the Snowdrift platform and mechanism.

Donate, share, and critique if you’re a fan of interesting mechanisms and freedom.

Posted in Commons, Economics, Open Services, Open Source, Public Goods | 4 Comments »

Ubuntu Ten

Thursday, October 23rd, 2014

Retrospective on 10 years of Ubuntu (LWN discussion). I ran Ubuntu on my main computer from 2005 to 2011. I was happy to see Ubuntu become a “juggernaut” and I think like many hoped for it to become mainstream, largely indicated by major vendor preinstallation. The high point for me, which I seem to have never blogged about, was in 2007 purchasing a very well priced Dell 1420n with Ubuntu preinstalled.

But the juggernaut stalled at the top of the desktop GNU/Linux distribution heap, which isn’t very high. Although people have had various complaints about Ubuntu and Canonical Ltd., as I’ve written before my overriding disappointment is that they haven’t been much more successful. There are a couple tiny vendors that focus exclusively or primarily on shipping Ubuntu-preinstalled consumer hardware, and Dell or another major vendor occasionally offers something — Dell has had a developer edition Ubuntu preinstall for a couple years, usually substantially out of date, as the current offering is now.

Canonical seems to have followed Red Hat and others in largely becoming an enterprise/cloud servicing company, though apparently they’re still working on an Ubuntu flavor for mobile devices (and I haven’t followed, but I imagine that Red Hat still does some valuable engineering for the desktop). I wish both companies ever more success in these ventures — more huge companies doing only or almost only open source are badly needed, even imperfect ones.

For Ubuntu fans, this seems like a fine time to ask why it hasn’t been even more successful. Why hasn’t it achieved consistent and competitive mainstream vendor distribution? How much, if any blame can be laid at Canonical’s stumbles with respect to free/open source software? It seems to me that a number of Canonical products would have been much more likely to be dominante had they been open source from the beginning (Launchpad, Ubuntu One) or not required a Contributor License Agreement (bzr, Upstart, Mir), would not have alienated a portion of the free/open source software community, and that the world would overall be a better place had most of those products won — the categories of the first two remain dominated by proprietary services, and the latter three might have gained widespread adoption sooner than the things that eventually did or will probably win (git, systemd, wayland). But taking a step back, it’s really hard to see how these stumbles (that’s again from an outsider free/open source perspective; maybe they are still seen as having been the right moves at the time inside Canonical; I just don’t know) might have contributed in a major way to lack of mainstream success. Had the stumbles been avoided, perhaps some engineering resources would have been better allocated or increased, but unless reallocated with perfect hindsight as to what the technical obstacles to mainstream adoption were — an impossibility — I doubt they made much of a difference. What about alientation of a portion of the free/open source community? Conceivably had they (we) been more enthusiastic, more consumer lobbying/demand for Ubuntu preinstalls would have occurred, and tipped a balance — but that seems like wishful thinking, requiring a level of perfect organizing of GNU/Linux fan consumer demand that nobody has achieved. I’d love to believe that had Canonical stuck closer to a pure free/open source software path, it’d have achieved greater mainstream success, but I just don’t see much of a causal link. What are the more likely causes? I’d love to read an informed analysis.

For Ubuntu detractors, this seems like a fine time to ask why Ubuntu has been a juggernaut relative to your preferred GNU/Linux distribution. If you’re angry at Canonical, I suggest your anger is misdirected — you should be angry instead that your preferred distribution hasn’t managed to do marketing and distribution as well as it needed to, on its own terms — and figure out why that is. Better yet, form and execute on a plan to achieve the mainstream success that Ubuntu hasn’t. Otherwise in all likelihood it’s an Android and ChromeOS (and huge Windows legacy, with some Apple stuff in between) world for a long time to come. I’d love to read a feasible plan!

Posted in Computers, Economics, Open Services, Open Source, Peeves | 5 Comments »

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).

Posted in Commons, Creative Commons, Economics, Inequality Promotion, Intellectual Protectionism, Open Access, Open Source, Politics, Wikipedia | 1 Comment »

LegacyOffice?

Wednesday, July 30th, 2014

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

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

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

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

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

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

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

Posted in Open Services, Open Source, Open Standards, Politics | 2 Comments »

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.

Posted in Commons, Creative Commons, Oakland, Open Access, Open Source, OpenHatch, Politics, Wikipedia | 2 Comments »

Open policy for a secure Internet-N-Life

Saturday, June 28th, 2014

(In)Security in Home Embedded Devices Jim Gettys says software needs to be maintained for decades considering where it is being deployed (e.g., embedded in products with multi-decade lifetimes, such as buildings) and the criticality of some of that software, an unpredictable attribute — a product might become unplanned “infrastructure” for example if it is widely deployed and other things come to depend on it. Without maintenance, including deployment of updates in the field, software (and thus systems it is embedded in) becomes increasingly insecure as vulnerabilities are discovered (cites a honeymoon period enjoyed by new systems).

This need for long-term maintenance and field deployment implies open source software and devices that users can upgrade — maintenance needs to continue beyond the expected life of any product or organization. “Upgrade” can also mean “replace” — perhaps some kinds of products should be more modular and with open designs so that parts that are themselves embedded systems can be swapped out. (Gettys didn’t mention, but replacement can be total. Perhaps “planned obsolescence” and “throwaway culture” have some security benefits. I suspect the response would be that many things continue to be used for a long time after they were planned to be obsolete and most of their production run siblings are discarded.)

But these practices are currently rare. Product developers do not demand source from chip and other hardware vendors and thus ship products with “binary blob” hardware drivers for Linux kernel which cannot be maintained, often based on kernel years out of date when product is shipped. Linux kernel near-monoculture for many embedded systems, increasing security threat. Many problems which do not depend on hardware vendor cooperation, ranging from unintentionally or lazily not providing source needed for rest of system, to intentionally shipping proprietary software, to intentionally locking down device to prevent user updates. Product customers do not demand long-term secure devices from product developers. There is little effort to fund commons-oriented embedded development (in contrast with Linux kernel and other systems development for servers, which many big companies fund).

Gettys is focused on embedded software in network devices (e.g., routers) as network access is critical infrastructure much else depends on, including the problem at hand: without network access, many other systems cannot be feasibly updated. He’s working on CeroWrt a cutting edge version of OpenWrt firmware, either of which is several years ahead of what typically ships on routers. A meme Gettys wishes to spread, the earliest instance of which I could find is on cerowrt-devel, a harsh example coming the next week:

Friends don’t let friends run factory firmware.

Cute. This reminds me of something a friend said in a group discussion that touched on security and embedded in body (or perhaps it was mind embedded in) systems, along the lines of “I wouldn’t run (on) an insecure system.” Or malware would give you a bad trip.

But I’m ambivalent. Most people, thus most friends, don’t know what factory firmware is. Systems need to be much more secure (for the long term, including all that implies) as shipped. Elite friend advice could help drive demand for better systems, but I doubt “just say no” will help much — its track records for altering mass outcomes, e.g., with respect to proprietary software or formats, seems very poor.

In Q&A someone asked about centralized cloud silos. Gettys doesn’t like them, but said without long-term secure alternatives that can be deployed and maintained by everyone there isn’t much hope. I agree.

You may recognize open source software and devices that users can upgrade above as roughly the conditions of GPL-3.0. Gettys mentioned this and noted:

  • It isn’t clear that copyright-based conditions are effective mechanism for enforcing these conditions. (One reason I say copyleft is a prototype for more appropriate regulation.)
  • Of “life, liberty, and pursuit of happiness”, free software has emphasized the latter two, but nobody realized how important free software would be for living one’s life given the extent to which one interacts with and depends on (often embedded) software. In my experience people have realized this for many years, but it should indeed move to the fore.

Near the end Gettys asked what role industry and government should have in moving toward safer systems (and skip the “home” qualifier in the talk title; these considerations are at least as important for institutions and large-scale infrastructure). One answer might be in open policy. Public, publicly-interested, and otherwise coordinated funders and purchasers need to be convinced there is a problem and that it makes sense for them to demand their resources help shift the market. The Free Software Foundation’s Respects Your Freedom criteria (ignoring the “public relations” item) is a good start on what should be demanded for embedded systems.

Obviously there’s a role for developers too. Gettys asked how to get beyond the near Linux kernel monoculture, mentioning BSD. My ignorant wish is that developers wanting to break the monoculture instead try to build systems using better tools, at least better languages (not that any system will reduce the need for security in depth).

Here’s to a universal, secure, and resilient web and technium. Yes, these features cost. But I’m increasingly convinced that humans underinvest in security (not only computer, and at every level), especially in making sure investments aren’t theater or worse.

Posted in Commons, Computers, Economics, Open Hardware, Open Services, Open Source, Programming, Public Goods | 1 Comment »

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

Posted in Commons, Creative Commons, Economics, Inequality Promotion, Intellectual Protectionism, Open Access, Open Source, Patents, Peeves, Politics, Public Domain | 9 Comments »

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?

Posted in Commons, Creative Commons, Economics, Inequality Promotion, Intellectual Protectionism, Open Services, Open Source, Open Standards, P2P, Patents, Politics, Public Domain, Semantic Web | 3 Comments »

« Older Entries
Newer Entries »