The Supreme Court decision in Oracle vs Google ends a decade-long nightmare for open source developers.
The decision of the US Supreme Court (SCOTUS) to reverse the erroneous conclusion of the US Federal Circuit appeals court (CAFC) that Google’s use of the Java SE API in Android was a copyright infringement comes as a great relief to open source programmers everywhere. Software developers have always assumed that merely including a function prototype in their code does not require copyright permission as it’s just a fact about the implementation.
Started in 1999 and established as an official corporate function in 2005, Sun’s Open Source Program Office (OSPO) was among the first in the industry and maybe the first to use the name.
As I’ve discussed in earlier posts, corporations are the vehicle for the collective expression of many individuals. However, to the outside world they are a monolith, and are expected to be consistent as well as predictable in their actions. With the many varied, implicit expectations and explicit obligations that different open source projects have, transforming a company’s reputation into that of a good actor in open source is a complex task. It’s also a necessary one if you expect other actors to invest their time and work in your project, or to give you influence in steering a project together.
Holders of zero-tolerance positions on both sides of the divide need to realise that accommodating open sourceproductively inside standards bodies is both viable and happening now.
You’ll recall that open source and open standards are orthogonal concepts where even the words they share (like “open”) are defined differently. That doesn’t mean they are mutually exclusive, nor that they are bad together – they can be cultivated well in the same garden. There is great value from accommodating the two orthogonal concepts so that neither is invalidated by non-mandatory elements of the other. When they combine, great value is unleashed.
Software freedom is important to as an idea, but it also creates all the value of open source for business and should be jealously guarded by OSPOs.
In talking about open source, I and others routinely use the expression “software freedom” to refer to the set of rights upon which the open source phenomenon is based. It arises as a synonym for “free software”, an unfortunately ambiguous term that leads people hearing it for the first time to conclude all the primary attributes of open source software relate to money — price, cost-of-ownership, license fee and so on.
“Software freedom” puts the focus in the right place — on the essential liberties required to benefit from the software. One problem with this alternative term is we are becoming accustomed to hearing discussions of “freedom” be limited to activist or political contexts, and consequently regard the term “software freedom” with caution. But a focus on software freedom isn’t just for the revolutionaries.
Is that single-company-controlled project actually open source in the sense of delivering software freedoms to you or just about delivering prospective customers to its host company? Here are 7 tests.
I frequently sum up the nature of open source licensing as granting permission in advance to developers or users to use, improve and share the software for any purpose. But the “Permission In Advance” lens has uses beyond just the rights to copyrights and patents granted in an OSI-approved license.
In my consulting engagements, I use a “thinking tool” to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy — both to join it and to host it — should begin with the question: “How confident are community members that they have permission in advance to do whatever they need to succeed?” The more reasons for confidence, the larger the community.
Here are some of the questions community members will be asking, perhaps silently, about single-company open source projects and their own agency as a member of the community:
Is your Open Source Program Office just part of your corporate defences, or is it the community’s advocate inside your company as well?
As we considered before, corporations are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, showing the outworking of the processes and systems they devise to embody their vision. So the work of an Open Source Program Office (OSPO) needs to address social change within the company and address community needs outside as well as compliance or other corporate self-protection.
Corporate open source maturity may be better evaluated by considering the actions of individuals and small groups statistically rather than evaluating the stated corporate strategy
It’s easy to forget that corporations (and indeed large non-profits) are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, as well as the outworking of the processes and systems they devise to embody their vision. Things happen not because a faceless corporation somehow chooses to act in a certain way from a point in time, but because of the persuasive decisions of actual people, acting within their belief systems and directing the work of others.
Every good – and bad – decision ultimately goes back to an individual somewhere, and corporate effects are in many ways emergent. So fitting a maturity model to a corporation may not be the best way to predict its future outcomes. That is a trailing indicator driven by the behaviours of the individuals within the company.
Interoperability is primarily a matter of the use case, not of the technology. Policymakers considering interoperability mandates need to be watchful for extremes of perfection or compromise, which both offer a game to be exploited by the unscrupulous.
Reviewers of a paper concerning interoperability complained that some sections seemed to imply only 100% functional equivalence would be acceptable, and told us “much smaller percentages are perfectly adequate.” So how much interoperability is enough interoperability? The answer, dear to the hearts of every politician, is “it depends”.
The coming wave of digital regulation may claim to target “Big Tech” but will inevitably end up harming citizen-innovators most because regulators have forgotten to include them in their process.
Here come the regulators. “Big Tech” companies like Facebook and Google definitely deserve some guide-rails, as well as some consequences for the unwanted impacts they have foisted on society along with the desirable ones. Facebook in particular has some deep, serious consequences of its amorality due soon. But so far, pretty much every regulation relating to the digital realm is defective.
It’s not new, even if each time it comes up people think it’s a new outrage.
One of the durable long-term strategies for software businesses in the era of open source was perfected by SugarCRM about a decade ago. I’ve described it as the rights ratchet model. The “ratchet clicks” (not necessarily in exactly this sequence) are: