In the light of the EU’s own research showing the huge impact of Open Source on Europe’s economy, the authors of these legislative instruments sought to ensure that the lifecycle of Open Source software was impacted as little as possible. Indeed, at FOSDEM 2023 the authors of the CRA and PLD said as much in their first-of-a-kind main track appearance. But when we all looked at the details, community members found that was not as true as we hoped. As a range of organizations explained, the CRA was likely to be an existential threat to Open Source development, because instead of placing all the compliance requirements of the CRA on companies deploying Open Source software for profit, the obligations as written potentially fell on developers and Open Source foundations.

Reactions To The Final Text

Many OSI Affiliates engaged with the European Commission, European Parliament and European Council during 2023. With the welcome coordination of Open Forum Europe, a group met regularly to keep track of progress explaining the issues. Many of us also committed time and travel to meet in-person. As a result of all this effort from so many people, the final text of the CRA mitigated pretty much all the risks we had identified to individual developers and to Open Source foundations. As the Python Software Foundation said in their update:

…the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

And the Eclipse Foundation wrote:

The revised legislation has vastly improved its exclusion of open source projects, communities, foundations, and their development and package distribution platforms. It also creates a new form of economic actor, the “open source steward,” which acknowledges the role played by foundations and platforms in the open source ecosystem.

As the Apache Software Foundation said:

So, all in all, this is mostly good news for volunteers who run and innovate with open source software. Or, more accurately, much better than most of us could have imagined at the end of last summer.

This time last year OSI recommended that the CRA:

…exclude all activities prior to commercial deployment of the software and … clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment.

That recommendation has been accepted and implemented, and the OSI is very grateful to the various experts who took the time to listen.

OSI Observations

While it’s all much better, and while the burden placed on individuals and charities is minimal, there are still challenges ahead. For example, the concerns that the Debian project articulated give cause for thought. With Open Source projects exempted from the requirement to place a CE certification mark on their software, downstream users will need to pay careful attention to their responsibilities under the CRA as well as to their liabilities to consumers under the PLD.

In particular, “digital artisans” using Open Source software at small scale – the main concern of Debian – will need guidance from the European Commission. While the experts we have met have all said that using an Open Source software distribution as part of a commercial activity is unlikely to require CE marking of the distribution itself, the interpretation of the key phrase “making available on the market” will need careful clarification. OSI encourages the Commission to seek expert advice from the Open Source communities as they did last year, and not to rely on outsourced consultants alone in preparing this advice.

FOSDEM 2024

There is also the question of how future engagement by legislators should proceed. The effort made by developers and Open Source foundations in 2023 is not sustainable, and the Commission needs to accommodate the Fourth Sector in future deliberations. To get this started, a group of us who have engaged during 2023 got together to organize a unique set of workshops at FOSDEM 2024 on Sunday February 4. If you want your voice heard, come along to one of the workshops!

Here’s a short list to help the co-legislators understand the engagement from the Open Source community.

• OSI and the experts with whom they engage are not trying to get all of Open Source out of scope as maximalist lobbyists do for other aspects of technology. An exclusion from the regulation for Open Source software per se would open a significant loophole for openwashing. But the development of Open Source software in the open needs to be excluded from scope just as the development of software in private is. Our goal in engaging is just to prevent unintentional breakage while largely embracing the new regulation.
• There is no one way to use Open Source. Many of the policymakers we’ve spoken to think of Open Source components in supply chains under the care of foundations like the Eclipse Foundation that are used essentially as-is. But the freedoms of Open Source are also used for stack building, consumer tools, enabling research, hobbyist tinkering, as the basis for European small businesses like XWiki, Open-Xchange, Abilian, and more. All these many other uses exist and are broken differently by the CRA. Software is primarily a cultural artifact and that aspect must be prioritized.
• There is no single Open Source business model. People make money from Open Source (by charging for it, running it as a service and supporting it) and with Open Source (by simplifying their businesses and reducing costs); they shape markets via Open Source by enabling adjacent businesses, commoditising competitors without then monetising their customers, and more – there are a significant number of business models made possible by software freedom. So any attempt to identify commerciality is sure to be model-specific and consequently have unintended consequences for other models.
• Even larger foundations like Linux Foundation do not actually employ the sort of staff who ensure code compliance – Open Source is conceptually disjoint from proprietary software. To comply with the CRA – if they find themselves in-scope – they will need them to hire a whole new operating unit. To them, the burden of compliance is not a cost of development funded by revenue as it would be for a manufactured physical good where staffing exists and just needs adapting.

As we did in January, OSI still recommends the Cyber Resilience Act should exclude all activities prior to commercial deployment of software and clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment.

“Open Source” means software under a license with specific characteristics, defined by the Open Source Definition (OSD). Among other requirements, for a license to be Open Source, it may not discriminate against persons or groups or fields of endeavor (OSD points 5 and 6). Meta’s license for the LLaMa models and code does not meet this standard; specifically, it puts restrictions on commercial use for some users (paragraph 2) and also restricts the use of the model and software for certain purposes (the Acceptable Use Policy). 

Why Open Source matters

An Open Source license ensures that developers and users are able to decide for themselves how and where to use the technology without the need to engage with another party; they have sovereignty over the technology they use. Open Source is premised on the understanding that everyone gets to share no matter who you are. The commercial limitation in paragraph 2 of LLAMA COMMUNITY LICENSE AGREEMENT is contrary to that promise in the OSD. 

OSI does not question Meta’s desire to limit the use of Llama for competitive purposes, but doing so takes the license out of the category of “Open Source.”  

The OSD does not allow restrictions on field of use because you can’t know beforehand what can happen in the future, good or bad. That’s what allows the Linux kernel to become popular in medical devices as well as airplanes and rockets. 

But the Meta policy prohibits use in several areas that might be highly beneficial to society, such as regulated/controlled substances and use for critical infrastructure. Even something that sounds as simple as “you must follow the law” is problematic in practice.  What if the law in different places is inconsistent? What if the law is unjust?

Avoiding adding more confusion

The license for the Llama LLM is very plainly not an “Open Source” license. Meta is making some aspect of its large language model available to some, but not to everyone, and not for any purpose. OSI realizes how important it is to come to a shared understanding of what open means for AI systems. These are new human artifacts, much like software was a new creation of human intellect in the 70s. We’re running a series of events to craft a common definition of “open” in the AI context and we welcome submissions of ideas.

Below is the text of the letter we sent.

June 16, 2023
Katherine K. Vidal
Under Secretary of Commerce for Intellectual Property
and Director of the United States Patent and Trademark Office
United States Patent and Trademark Office
600 Dulany Street
Alexandria, VA 22314-5796

Dear Director Vidal,

The Open Source Initiative (OSI) is a California 501(c)(3) public charity advocating for and enabling the benefits of open source (community developed and maintained) software in the interests of every citizen. It does not advocate on behalf of any for-profit entity or any political group.

We very much appreciate that the USPTO has provided the opportunity for input on this important matter in advance of the formal rulemaking process. OSI is writing in particular to provide information for your consideration regarding the use of third-party entities to challenge patents.

The oversight of each open source project is usually in the hands of an unincorporated association of individual contributors, or a dedicated public charity (like OSI’s 80+ Affiliate members). Many of the leaders in these communities are entrepreneurs leading small businesses. Open source projects use OSI-approved licenses, which openly convey all rights necessary to use, improve, share and otherwise enjoy the software without any necessary relationship with its rights holders. As such, no open source project depends on patents and communities rarely tolerate royalty-due elements, preferring to design without any encumbered parts.

Open source projects and their maintainers are uniquely vulnerable to attack by hostile parties such as patent trolls (sometimes called “non-practicing entities”) and companies rent-seeking over so-called standard-essential patents. The projects and their non-profit fiduciary hosts are not of a scale to be able to manage the usual defenses of large corporations, while the individuals themselves may seem worthwhile targets for avaricious litigators. When a project faces a patent attack, it is thus frequently defended by others as a matter of civic duty.

The rule changes that the Patent and Trademark Office propose would greatly limit the ability of open source projects to be defended by these third parties. This would both chill the innovation and progress arising from open source software – which contributes billions to GDP – as well as embolden malicious litigators seeking reward where they have no claim simply because their victim is unable to defend themselves.

OSI consequently encourages the USPTO to reconsider these rule changes and avoid the harm they would cause open source software.

Your sincerely,

Stefano Maffulli
Executive Director
Open Source Initiative

Open Source Initiative is a 501(c)(3) corporation (EIN:  91-2037395).

Proprietary software and the company that places it on the market can usefully be seen as the same target for those creating legislation. The software is constructed in secret, under the control of a single party, and the controlling party is responsible for both funding the work and monetizing the result. However, the same cannot be said for Open Source software, which is created openly by a globally-distributed and unaffiliated community whose relationship with the larger work is “volunteer”. Using terminology associated with the worldview of proprietary software in legislation that affects Open Source is at best ambiguous and at worst extends consumer regulation to the domain of research and development.

Open Source software is an artifact arising from the interactions of a community of contributors with no contractual binding between them beyond the Open Source license itself, which disclaims all warranties and has no conduit for funds. If there is an Open Source charity or trade association hosting the community, there will also be only a limited binding to it and probably none that is a funding conduit. Many communities are unincorporated and don’t even have this level of interconnection.

Because of this, those who place the artifact with digital elements on the market must be assumed to have no financial, organizational or indeed morally relevant relationship with any other party involved in the artifact’s origination or use until proven otherwise. There may be links, but it’s best to start from the assumption there will be none because making them is an outside activity with no accommodation in Open Source licensing.

In many cases (sadly) those placing the artifact on the market have no connection at all with the community, not even at the level where it is appropriate to consider members of the community as suppliers. As one community member wrote:

I am not your supplier. So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code.

The software and the community thus need to be considered separately when choosing language that applies regulation affecting Open Source. Some highlights to note:

• The software is made freely available under an OSI-approved license that ensures its consumer may do anything it wishes without needing any relationship with rights holders.

• The members of the community collaborate for many different reasons, and even when those reasons have commercial intent the commercial intents in play are likely to be unrelated both formally and informally.

• Many community members have a moral/ethical basis for their participation which can sometimes take priority over pragmatic convenience.

• Treating the software and the company placing it on the market as interchangeable is unsafe.

• As a consequence, it is unsafe to assume that because two parties are monetizing a piece of Open Source software, that there is a flow of funds or even a relationship between them. Regulation should only apply to the party triggering the clause in the legislation, unlike with proprietary software where it is reasonable to assume a link.

This article first appeared on Webmink in Draft.

Image of Fallen Head by Simon Phipps

But reciprocal patent licensing is very common in the software industry generally and Open Source in particular – it’s part of the terms of the Apache License for example – so the accusation seemed far more likely to be projection by the SEP-dependent legacy industries of Europe. One useful insight into the whispers to which DG COMP responded can be seen in the extra information AOM has added to its legal page in response to the matter. The questions they address have such obvious and innocuous answers that only express sophistry could have been behind such questions, given the sophistication of the actors involved.

This is all crucially important to Open Source software, and not just as an endorsement of reciprocal terms. While there are edge cases, generally Open Source projects avoid standards which embed royalty-due patents, not primarily because of the royalties but because of the need to submit to the control implied by privately negotiating terms with the patent holders – an obviously anti-competitive aspect for any market entrant, about which Europeans complain.

It only takes one patent aggressor to rob everyone of viable Open Source video, so it seems entirely reasonable to scrupulously maintain hygiene by requiring any beneficiary of AV1 to commit to waiving royalties (and thus their negotiation). AOM is creating standards expressly intended to allow implementation by Open Source projects, so their terms are both rational and reasonable … unless you want to keep Open Source out of your cozy market.

The clouds have not all dispersed. AOM’s licensing is unfortunately based on a non-OSI-approved license (for excellent reasons but still an issue). Hopefully this will become more and more unfashionable as Open Source expands its reach. Also, significantly, there are hostile patent pools which, unfathomably and without evidence that their mountain of claims are actually essential, assert that the AV1 standards infringe patents in the pools.

But this is good progress and underlines that the “reciprocal” mechanisms so common in Open Source licenses are generally pro-competitive.  Perhaps the Commission will now move on to ask why such an obviously anti-competitive arrangement as standards bodies permitting royalty-due patents in their specifications is still tolerated?

This article first appeared on Webmink in Draft.

Image it’s not thieving if it’s from the bin, right? by Simon Phipps.

There’s a crucial issue here for Open Source. EU policy experts say not to worry about CRA compliance because the EU standards bodies will streamline it. But the European Standardisation Organizations (ESO) are corporate-controlled, patent-loving and expensive to engage. Shouldn’t the EU address this if they want Open Source accommodated?

In Europe, standards requests from the European Commission are handled by bodies which have been designated an ESO under EU law. There are only three of these; CEN, CENELEC and ETSI. None of these standards development organizations are accessible to Open Source projects per se.

CEN and CENELEC are largely controlled by national standards bodies which in turn are dominated by national industries, while ETSI is a  member organization with high membership fees and largely secret proceedings (although laudable with free specifications) that is directly controlled by its members, predominantly from the telecoms industries but also including the European states. In addition, ETSI celebrates its role as a pioneer and proponent of FRAND licensing, which is fundamentally incompatible with Open Source communities. As with all de jure standards, participation in each of these standards bodies is expensive, both financially and in time, and engaging in their governance is beyond the scope of small players.

Given this context, when the European Commission requests standards that will be applied for conformity assessment, it’s not clear how they will take into account the development workflow that applies to Open Source software. Like the European Commission itself (as I commented recently), Europe’s standards bodies have no functional relationships with Open Source charities and do not consult them.

It is very important to find ways to give a voice to the true community and not just its corporate members. As things currently stand, Open Source will only be considered through the lens of its corporate uses. Since Open Source is a social movement with software artifacts for which the applications are diverse, paying heed only to the attributes of the software and the needs of the companies consuming it is an inadequate approach. You can’t even proxy through small business, let alone multinationals and their lobbyists – many of them are unaware of how communities work and without community understanding, fundamental errors can be made.

As a result, I believe whatever legislation arises from the CRA (and related instruments) needs to specify that standards bodies making related standards must include effective measures to consult and include the Open Source community. If this doesn’t happen, as NLnet Labs explained, “The only alternatives left available are the conformity assessment procedures that involve paying for third-party process auditors.”  And Open Source developers definitely can’t afford that.

This article first appeared on Webmink in Draft.

Image Walls Within Walls by Simon Phipps.

The CRA rightly addresses the need for commercial suppliers to protect their customers from exploits and cyber attacks. But legislators have exposed the open development of software itself to the regulations rather than just the for-profit use of Open Source artifacts in the marketplace. They are incorrectly assuming that Dirk Riehle’s terminology calling single-company projects “commercial Open Source” means it’s possible to use the “commerciality” of an application to distinguish single-company activity from community projects, and by using the concepts of proprietary software to then define boundaries.

There will be no escape from this for European projects like the Eclipse Foundation, but projects outside Europe — especially smaller projects — may just decide to erect geo-blocks and not deliver their work to European IP addresses. CRA-motivated geo-blocks start with needing to seek legal advice because it’s so confusing/unclear, only then to be told “maybe,” leaving you to make the decision on your own.

One response when I raised this was to say that the European Union is a massive and valuable market, and projects would not risk being excluded from it by geo-blocking. But this argument ignores the fact that just because Alice deploys some code profitably in Europe, it doesn’t mean Bob in Nebraska who wrote the code will share in the profit, whether he’s in business or not where he lives. Open Source licenses do not create a relationship in which financial reward is guaranteed.

Geo-blocks have happened before. Many small global publications block access from the EU rather than resolve legal uncertainties with GDPR. But the risk of CRA-related geo-blocks is much more consequential because reading those sites is optional whereas much Open Source software maintained internationally is woven into the fabric of Europe’s infrastructure.

In addition, those avoiding evaluating their GDPR responsibilities (or evading them after evaluating them) are likely to fear compliance will impact the benefit they gain from surveillance advertising, while for Open Source developers the perceived risk is of being the target of a punitive bureaucracy for failing to complete paperwork that adds nothing to their work.

If the confusion persists, Open Source projects will need to thoughtfully consider how to proceed. Disentangling dependencies that choose to pragmatically block Europe will be traumatic; should they be forked or substituted? Things could get very messy. Let’s hope the co-legislators see sense, finally talk to the Open Source community and address the issues.

This article first appeared on Webmink in Draft.

Image created by Simon Phipps featured on Webmink in Draft.

The conference program places two talks back to back titled “The goals of Open Source AI” followed by “The goals of a Free Software AI”… But to me, the distinction between Open Source and Free Software is insignificant. Open Source is the English term for something I’d call Software Libero in Italian. It’s time we stop making a distinction that only a small cabal understands and the general public tend to ignore and worse – misunderstand.

I started looking into AI with the fear its complexities might make Open Source irrelevant. I say this after seeing what happened when two crucial technologies, the iPhone and AWS, passed us by and I don’t want to repeat the mistake. Both radically impacted how software is distributed and executed, but the Open Source communities under estimated that impact. There were reactions like: ‘cloud is someone else’s computer’ and ‘iphones are locked, don’t use them.’

Today, the values of Open Source are largely foreign in both mobile and cloud.

If we miss addressing the impact of AI, too, we could kiss over 35 years of history goodbye, wrap it up and go fishing.

So what is the OSI doing about it? Last year, we started an investigation to understand the AI topic from multiple angles. TL/DR: This thing is useful, dangerous and introduces new digital artifacts. More on the report.

As long as we’re talking about nomenclature, I use the term Artificial Intelligence to refer to Machine Learning, Large Language Models, Deep Neural Networks and all of those systems. I’m aware of the over-hype around the supposed “intelligence” of modern systems. At the same time, the term AI is more than 70 years old and tied to a well-established scientific discipline. I find alternatives proposed by some groups (SALAMI or other) reductive of the importance of the topic. Let’s keep it serious, there’s legislation coming and legislators call it AI, too. We will keep using this term while remaining skeptical of the hype.

Open Source origin story 

It’s worth remembering that in the early days of computer science, software was widely available and not covered by copyright. The hacker community at MIT AI Lab had complete freedom to run, copy, share and modify software. It was the introduction of copyright and secrets that forced Richard Stallman to devise a hack and introduce copyleft. Then came the GNU Manifesto and finally the GNU GPL. This sequence is important.

As a new artifact of human production came to exist (the software), a community was established around principles (like the Manifesto) to create new software (the GNU operating system) shared with a legal agreement that subverted the system (the copyleft license). 

Then, software was relatively simple: source code written by a human in an understandable language, irreversibly transcoded by a compiler to machine-readable code (the “binary”). It wasn’t until the 70s that copyright was applied to software, too. In the US it wasn’t until Apple v. Franklin in 80s that it was clear that software fell under copyright protection.

Copyright puts obstacles to sharing knowledge and innovation. So the GNU Manifesto sets out the Golden Rule:

If I like a program, I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others.

And then lists benefits of the GNU operating system:

• […] much wasteful duplication of system programming effort will be avoided
• Schools will be able to provide a much more educational environment… by encouraging all students to study and improve the system code
• […] the overhead of considering who owns the system software and what one is or is not entitled to do with it will be lifted

The Golden Rule and its benefits can be easily adapted to modern AI systems, substituting the word “program” with “AI system”.

If I like an AI system I must share it with other people who like it.

What do I need to share such an AI system?

Open Source AI is built on data

Modern AI is built on three components: hardware, knowledge and data. Acquiring hardware is only a function of money: richer organizations can procure enough GPUs and other custom chips fairly easily, like the recent announcement by Elon Musk shows. Legally, there aren’t many obstacles.

Knowledge is a function of time and money. There aren’t many developers and system engineers capable of setting up clusters suitable for training large AI systems. But groups like EleutherAI, LAIoN and others demonstrate that it’s not too hard to collect enough knowledge to train complex models.

Data, instead, is a function of a variety of factors. First, large models require large datasets…ginormous. The Pile, used to train LLMs by EleutherAI is 825 GiB (JSON compressed). For comparison, all of Wikipedia is 43 GiB (XML uncompressed.)

Assembling large quantities of data is a technical challenge that’s also full of legal obstacles. Data is covered by a variety of laws and regulation: copyright, sui-generis rights (database), a variety of privacy laws (different all over the world), terms of use, bilateral contracts. 

AI systems are not as simple as software in the 70s. There isn’t simply source code and binary. To create a GNU Manifesto for an Open Source AI, we need to start from data, because creating large datasets is not a simple function of time, money or knowledge.

Liberating data the first step for an Open Source AI

Visual artists and developers reacted to the brouhaha following announcements by OpenAI and other large corporations with copyright. “Thou shall not use [My code|my art] in your dataset.”

This approach goes directly against the declared objectives of the GNU Manifesto adapted to AI. Putting obstacles based on copyright to the aggregation of data forces users to agree not to share with others. The benefits for schools would be removed, vast amounts of overheads would be added.

Plus, by putting obstacles to data mining we’re not preventing large corporations from accumulating data anyway. We’re leaving this space to the big tech and big government agencies who already proved to be good at accumulating data..

I’d argue that creating datasets is already highly regulated by other laws. Anti-discrimination, consumer protection, human rights, disability protection, privacy, national security laws, and many more legal frameworks. Why add copyright on top?

Instead, we should consider this an opportunity to remove copyright as much as possible to produce and spread knowledge and freedom. This is an historic opportunity to set new norms, just like copyleft hacked the legal system imposed on software back in the day.

Open Source has been spectacularly successful addressing the proprietary, secret, overly protected software made and distributed by software vendors. However this was due to a combination of factors (nature of the software, concept of derivative for copyleft, actual distribution of the software, intrinsic inefficiency of proprietary development in many many fields, etc.), favorable to creating and maintaining commons that work. The same tools don’t apply to other fields, like data.

Keep the models out of copyright, too

The elaboration of datasets are the models. For these we don’t need copyright, either. The upshot: We shouldn’t really be thinking about writing AI licenses.

But how can we protect the public from abuse? How can we keep paying jobs for writers, artists? How can we prevent mass disinformation campaigns and all the other doomsday scenarios we read every time ChatGPT is mentioned?

My bet is that already we have all the laws we need to keep things under control. Anti-discrimination, labor protection, privacy, accessibility, slander and defamation, all either already have provisions or can be amended to cover new corner cases opened by AI.

Conclusion 

The values in Open Source are encapsulated in its Definition, but can be distilled to “autonomy, transparency, frictionless innovation, education, community improvement”. The licenses are a way to enable these things in the face of copyright law that defaults to the contrary. The licenses are not the mechanism to achieve these goals. Instead it’s the community and innovation that they produce when you remove legal barriers to collaboration.

The licenses do something else: they remove liability for sharing, and this lack of liability has been instrumental in allowing people to share. Upcoming regulation will block collaboration and sharing, both for software and ML, and we should be exploring terms and mechanisms to avoid the negative consequences of those new legal blockers to sharing as much as we can.

It’s time to put our heads together not to write new licenses but to support policy makers so that Open Source can flourish in AI as it did in its early heyday. Reach out to me on Mastodon.

Image from Alma Studio via Canva.com

By popularizing and catalyzing the pre-existing concepts from the free software movement, Open Source has been at the heart of the connected technology revolution for 25 years. Open Source licenses grant all the rights necessary for anyone and everyone to use, improve, share and monetise the software powering modern systems and networks, empowering collaboration with many “known others” to create results greater than any could alone. Open Source Approved Licenses® are the hidden power behind Linux, Apache, Mozilla, Android and more.

But by granting all the rights necessary to evolve the software powering modern systems and networks, Open Source also unreservedly grants permission to “unknown others” to repurpose, rehost, reuse and revolutionize. It also allows digital archivists to store, refactor and renew the means of access over the long term.

Availability to the “unknown others” — to society in general, and to our descendants — is crucial to our future. When software stays locked up inside the corporation or institution, when code created by the state with public funds remains secret, it does not add to our collective knowledge and the innovation it embodies is lost to society when the “owner” moves on. This was the original motivation for previous generations to create temporary intellectual monopolies as an incentive to creators to make their creations public.

As time has passed, those intellectual monopolies have themselves been regarded as property and the knowledge and culture they embody is increasingly withheld from society using that as a pretext. Open Source allows that new-found wealth to be “spent” in a new way to stimulate collaboration. Collaboration in the community has gone on to amplify innovation and accelerate adoption. It’s thus especially important that software funded with public money finds its way into Software Heritage.

Software Heritage completes the new social contract enabled by Open Source. It provides the ultimate historical reference for the code behind our culture and comprehensive library of innovation to provide a “mounting block” to the shoulders of the giants before us. We should strive to get all the software that matters into this new internet archive for code.

Software is a cultural artifact, a proxy for the law in the lives of every citizen, a tool for control and for freedom depending on the hand that wields it.  It is imperative that all software is open for scrutiny and preserved for posterity.