An interview with Simon is featured on the web site at Open Forum Europe at the moment.
Simon co-hosted the FLOSS Weekly interview with BitCore, a node.js interface for bitcoin and its blockchain.
In a thread on Twitter, the CTO at Chef Software defended the company against the accusation from an open source contributor that it demands copyright assignment from contributors. Chef’s CTO Adam Jacob explained that the company does copy Apache rules and thus requires a copyright license agreement (CLA) in addition to Apache’s open source license – not copyright assignment. He said:
we have never asked for copyright assignment. We do ask for a license, as Apache license requires.
That’s not actually correct, even if it’s a sufficiently common misunderstanding that Jacob really shouldn’t be called out for asserting it (especially as he was probably just suffering from Twitter’s 140 character limit!). Copying Apache’s license does not imply you should copy the rest of Apache’s CLA practice. The Apache License v2 (ALv2) is the best choice among non-reciprocal licenses for new projects, mostly because it includes explicit patent licensing. It is a perfectly effective license to use for any open source project where the community has no expectation of contribution on the part of users of the code, as it conveys all the rights you need to work with the code independently of others. Continue reading
While in 2015 Simon spent most of his time working at Wipro, 2016 sees his return to full time leadership of Meshed Insights with renewed energy and several new projects. Follow on Google+ for regular updates.
As an example, we’ve been retained by Mozilla to compile a report describing the entities that could host the Thunderbird Project, and have two other (currently non-public) clients ready to go. We would welcome further engagements for 2016 and would be thrilled if demand allowed us to hire more staff.
In addition to those client engagements we have ideas relating to the thinking we’ve been doing around Community Interest Companies and open source communities, and hope to have news about that after FOSDEM.
If you have activities that would benefit from our unique understanding of the way the meshed society is replacing the hierarchical world of the industrial society, get in touch now or schedule a consultation instantly.
A frequently asked question in the world of free and open source software (as well as the origin of many disputes) is “Which open source license is best?”
Unlike bilateral copyright licenses, which are negotiated between two parties and embody a truce between them for business purposes, multilateral copyright licenses — of which open source licenses are a kind — are “constitutions of communities”, as Eben Moglen and others have observed. They express the consensus of how a community chooses to collaborate. They also embody its ethical assumptions, even if they are not explicitly enumerated.
When that consensus includes giving permission to all to use, study improve and share the code without prejudice, the license is an open source license. The Open Source Definition provides an objective test of evaluating that such a license is indeed an open source license and delivers the software freedom we all expect.
Since licenses are the consensus of communities, it is natural that different communities will have different licenses, that communities with different norms will find fault with the licenses used by others, and that all will regard their way as optimum. The arguments over this will be as deep as the gulf between the philosophical positions of the communities involved.
Ultimately, there is no license that is right for every community. Use the one that best aligns with your community’s objectives and ethos. Meshed Insights can help you select an open source license for your project as this is not primarily a legal matter; please contact us.
[Now adopted as part of OSI’s official FAQ]
The Linux Foundation started a blockchain initiative involving many of its large corporate members. The initiative will devise a viable new approach to blockchains (presumably implemented as open source software) that can be used for any application where a distributed ledger is a useful data structure.
It’s easy to confuse “blockchain”, a distributed document database technology that operates without an authoritative master copy, and “bitcoin”, a virtual currency associated with one particular instance of blockchain technology. So here’s an explanation of the blockchain.
The “blockchain” is a database, journal or ledger for storing arbitrary documents. It’s maintained as a linked list, with cryptographic signatures verifying each entry. As a public resource, there’s a risk of journal entries being made too often (a bad thing for performance, especially over time, creating a risk of DoS). To prevent this, every entry needs to be accompanied by a token indicating the good standing of the author.
Since issuing tokens from a central authority defeats the purpose of the blockchain, they are instead created by each author independently but verifiably. For the Bitcoin blockchain and many others, the token takes the form of a “proof of work” – a cryptographic evidence of having solved a computationally-complex cryptographic problem within a globally-identified sequence.
There is no master copy of a blockchain; copies of it may be kept anywhere. The validity of each entry in the blockchain can then be independently confirmed by every participant. In the case of the Bitcoin blockchain and many others, this is done by every user replicating the entire blockchain and then comparing new entries against the findings of other users. A voting mechanism between replicas allows the “wisdom of crowds” to identify and reject flawed or fraudulent entries. The crowd involved can be public (as in the case of Bitcoin), or private or indeed a mixture of both.
While Bitcoin is the best-known application of the blockchain, there are many others, including different approaches to the entry token and to cryptography. We expect blockchain to become an important part of distributed systems in many roles: creating auditable logs of transactions, establishing provenance of reference documents such as inventions or contracts, providing a micro-currency for automated transactions in a heterogeneous “internet of autonomous things” and many more beyond the familiar use as a virtual currency.
[Did this help? You can use Bitcoin to leave a tip! See right margin ⇨]
While some may assert that open source is not applicable in every circumstance, the right to demand access to source code in situations where it is appropriate is important to society as a whole. That’s why it is important to note — and protest — a clause in the Trans-Pacific Partnership trade agreement (TPP), and any other trade agreements carrying the same idea. As the FSF notes, chapter 14 includes a prohibition on governments requiring access to source code as a condition on allowing
the import, distribution, sale or use of such software, or of products containing such software, in its territory.
Just as Volkswagen was able to hide its evasion of emissions regulations behind proprietary code (which the US DMCA and laws like it globally even made it illegal to reverse engineer for scrutiny), so TPP enshrines the ability to hide behind proprietary code and prohibits governments from mandating its disclosure even when that’s in the interests of the citizens they serve. In the future, regulations should increasingly require open source for code critical to regulatory matters; this clause prohibits it. Shutting such an obvious avenue for society’s good seems premature and regressive.
It’s not enough to partially mitigate this ban on open source by allowing secret disclosure to governments. Our perspective is that simply having source made available for viewing by select parties is not sufficient. Source code related to public regulatory matters should be released under an OSI approved license and thus made available to all those who use the software. Doing so allows them to study, improve and share the software as well as to check that their lives are not negatively impacted by its defects. Ideally, all software written using public funds should also be made available as open source.
There’s much else in TPP to be concerned about, as the EFF notes, but this clause is especially regressive and is cause alone to reject the agreement. The clock is ticking — President Obama notified Congress on November 5 that he intends to ratify TPP on behalf of the USA — so the time to protest is now.
[Adapted by OSI as a Board position statement]