OSI Affiliate Member Powering Potential Inc. (PPI) is currently preparing for their annual fundraising event scheduled for Wednesday, June 5, 2019, from 6 to 8:30 p.m. at NoMad Studio, located at 29 W. 39th Street, 10th Floor, in New York City.
This year PPI celebrates their 10 Year Partnership with the Segal Family Foundation. The close, long-time relationship has been a key factor in the amazing progress PPI has made in bringing their “Educating through Technology” programs to the rural students in Tanzania.
Proceeds from this year’s event will go towards the Sazira Secondary School SPARC+ Lab Upgrade impacting 800+ students in rural Tanzania: an ambitious project needing $23,500. While this is significant, The Collegiate Churches of New York recently awarded Powering Potential a generous grant of $13,000 towards this goal.
PPI has an incredible event planned for their guests. Back by popular demand, Tanzanian dancers performing traditional dance led by Justa Lujwangana, CEO and founder of Curious on Tanzania will provide entertainment for the evening. A buffet will also feature authentic Tanzanian dishes based on menus from Taste of Tanzania by Miriam Malaquais. The author has donated twenty of her books for sale at the event with proceeds going to PPI.
Along with wine and soft drinks, a classic Tanzanian cocktail will be available to guests for a donation. The Dawa is a mixture of vodka, lime juice and honey. The word “dawa” is Swahili for medicine.
This year's event will also feature a Silent Auction with a variety of exciting items and services up for bidding.
Admission is $70 for early bird admission. Regular admission is $90 at the door.
Visit Poweringpotential.org to donate and reserve your space at this event.
Asante sana (thank you)!
PALO ALTO, Calif. - May 14, 2019 - The Open Source Initiative (OSI), the founding organization of the open source software movement, is excited to announce the Affiliate Membership of the Open Source Hong Kong (OSHK). For ten years OSHK has worked across Asia to support open source communities, foster open source development, and increase the use of open source software, their recent OSI Membership highlights both organizations' desires to collaborate across communities.
“OSHK mission is promoting Open Source Software projects in Hong Kong and foster its development by connecting to the global open source community. In joining OSI as an Affiliate Member, OSHK connects with OSI, and other open source organizations, to support the promotion of open source,' said Sammy Fung, President of OSHK. "Open Source Software is not just about viewing the source code, it also guarantees the right to use the software, and modify it for our own use. By working together, I believe both organizations will be able to extend our reach and missions."
“We are excited to welcome OSHK as an OSI Affiliate Member,” said Molly de Blanc, OSI President. “The open source community truly is global, and their dedication to that idea is what inspires us as an organization. Our work for the future of open source is driven by that global community, and having the voices of OSHK in our affiliate membership helps us meet our goal in promoting and protecting open source and communities. We look forward to supporting their efforts and collaborating to help spread the message of open source even further.”
Currently, OSHK organizes the Hong Kong Open Source Conference (since 2013) and PyCon Hong Kong (beginning in 2015), with hopes to extend those event―and even add additional opportunities for open source communities to meet and collaborate. As a global organization the OSI is keen to help promote OSHK’s current events to both regional communities and our partners worldwide, as well as help develop new venues to raise awareness and adoption of open source software. As a growing segment in a large market, Asia promises to be a vital community in open source development and innovation. A partnership between OSI and OSHK will be critical in continued success.
The OSI Affiliate Member program allows non-profit and not-for-profit organizations to become OSI members. Full details of OSI Affiliate Membership and the names of the Affiliate Members are available on OSI's Affiliate Membership pages (www.opensource.org/affiliates) together with details for other non-profit and not-for profit organizations on how to join. Individuals can also become Members at www.opensource.org/join
About Open Source Hong Kong
Established in 2009, Open Source Hong Kong (OSHK) serves to foster and promote open source communities of and for developers, contributors, engineers, promoters, and users. OSHK develops and supports open source projects, and organizes conferences and events,within Hong Kong and across Asia, to encourage collaboration in the global open source community. To learn more about OSHK, visit: https://opensource.hk/about/
About The Open Source Initiative
Founded in 1998, the Open Source Initiative (OSI) protects and promotes open source software, development and communities, championing software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition, and preventing abuse of the ideals and ethos inherent to the open source movement. The OSI is a public charity with global vision based in California. For more information about the OSI, please see https://opensource.org.
I spent last week in New York at the annual new-inductees face-to-face Board meeting of the Open Source Initiative Board (pictured here – Christine Hall is also a member but was unable to join us). Having spent the last 11 years working on refactoring OSI for a new generation, I had advised the Board in advance that I intended to step down as President to make way for fresh blood. The Board elected Molly de Blanc as the new President and Josh Simmons as Vice President, with Hong Phuc Dang bravely volunteering to be CFO. I agreed to serve as Board Secretary until someone else feels ready to play that role – no later than next April when my term ends.
Simon Phipps, Elana Hashman, Pamela Chestek, Molly de Blanc, Faidon Liambotis, Chris Lamb, Hong Phuc Dang, Patrick Masson, Carol Smith (kneeling) Josh Simmons (kneeling)
The OSI I’m handing over to the new Board is very different to the one I first attended in 2008 (as an observer - I only joined the Board on leaving Sun in 2010). It is now elected rather than selected (albeit via an indirect mechanism to make California regulation easier to manage). The electors are over 60 affiliate organisations representing the majority of the world’s core open source developers and an ever growing community of individual members. OSI now has a viable income arising largely from a diverse range of around 30 sponsors. It now has a staff, including a full-time General Manager, Patrick Masson. It now has maintained systems for managing donations, lists and outreach. And there’s more been achieved – those are just stand-outs.
All together that means OSI has a proven foundation for the new Board to build upon. Already built on that foundation there are a postgraduate curriculum, a programme to advocate open source in the world of standards, a programme to equip schools with recycled PCs, working relationships with peer organisations like FSF and FSFE and more. There are many people responsible for all this change, too many to name here, and I thank them all.
People always look forward rather than back and there are still plenty of issues to deal with which are the new Board’s focus. We are already working to improve the license review process, for example. But I’m really pleased with what we have all achieved over the last decade at OSI (and how it matches my 2010 manifesto!) and am thrilled that there’s an energetic, more diverse and younger crew taking over.
In April, the License-Review mailing list saw extensive debate on the Cryptographic Autonomy License, in particular:
The corresponding License-Discuss summary is online at https://opensource.org/LicenseDiscuss042019 and covers discussions about non-commercial licenses, license revocability, and LGPL/Apache compatibility.
Van Lindberg submits his Cryptographic Autonomy License (CAL) to the review process. This is a network copyleft license, but with a broader scope than the AGPL. The CAL is motivated by ensuring user autonomy in blockchain-based applications. Lindberg has also written an in-depth blog post that serves as a rationale document. Last month, there had already been preliminary discussion about the license on the license-discuss list (see the summary).
Note: this summary uses the term “operator” to describe a user who runs the software so that other end users can interact with it.
While the license presents welcome innovation in the network copyleft licensing space, there is also major criticism:
While Perens was eager to get his concerns heard early, Richard Fontana reminds that no urgency exists: as per the review process, new licenses get an initial 60 days of discussion before any decision. Simon Phipps adds that since Fontana's tenure as license committee director has ended, any review progress will be stalled until a replacement is appointed at the next board meeting.
Bruce Perens is concerned that the CAL goes beyond licensing software, but tries to establish some market. Perens suggests that the license's business purpose might better be reached through an ordinary contract.
Van Lindberg [1,2] responds that while the CAL is being drafted because of a business purpose, its terms are independent of that purpose. The terms only cover licensing of the software, under some conditions. Ultimately, every license has some purpose behind it. In the case of the CAL, the business purpose required a network copyleft license.
Perens argues that while other licenses may have their own purpose, they are not specific to some application. In contrast, the CAL seems specific to blockchain applications.
The CAL requires that operators must provide user data to which an end user has a lawful interest. For example, a user might have a ownership interest in the photos they upload to a photo storage service.
Bruce Perens [1,2,3] thinks that “lawful interest” is not sufficiently defined, and would require novel theories of data ownership: “There are opinions, and little case law.” This could even require disclosure to third parties if they establish a lawful interest.
Van Lindberg [1,2,3] responds that lawful interest is defined using known legal terms. The CAL does not grant new rights to user data: either the law recognizes some kind of data ownership or it does not. You can't end up with rights that you didn't already have.
Lindberg clarifies that the CAL references the GDPR not to define lawful interest, but to clarify how an operator must provide user data.
Perens points out: if the users already have a right to their data, why does the license need terms to that effect? Lindberg responds: “Just because I have ownership of data does not mean that you have an existing legal responsibility to give it to me. This is exactly the problem addressed by the CAL.”
The insight is that, increasingly, the data and the code are needed together to realize the program's function. Existing open source licenses, such as the GPLv3 family, recognize this and requires the provision of cryptographic keys that would prevent the execution of the code. The CAL recognizes that user freedom also includes the provision of the user's data so that the program functions completely and fully in a context of the user's choice.
[…] I may own my data. I may be able to get a copy of the source code. But […] unless I can use the software to process my own data, I also don't have effective freedom.
The CAL does not encumber or restrict user data, it just prevents it from being locked into a platform – similar to GPLv3's anti-Tivoization clause. Such a clause is necessary because hashchain applications offer new ways to lock down a program.
Bruce Perens is not convinced that end user freedom requires the disclosure of this user data. And the license must protect freedom not only for end users but also for operators, so why should it be acceptable to compel operator actions?
Pamela Chestek and Bruce Perens disagree with the comparison to the GPL's anti-Tivoization clause. It applies when a device with embedded software changes ownership, so that the new owner can install modified software on their hardware. In contrast, the CAL's user data provisions burden the operator of the software to provide access to user data. This is a fundamentally different kind of obligation.
The CAL's requirements trigger on mere use of the software, which looks like an OSD #6 and #9 violation. How can forbidding or compelling an action not be a usage restriction?
It should be fine to just run software under an OSI-approved license, without having to read it. The CAL's user data requirements break this expectation. Operators have to hire a lawyer to understand the extent of their obligations. This is an unreasonable burden that limits their freedom.
The CAL affects data that is processed with the software.
The CAL's user data requirements are about as restrictive as the AGPL's source disclosure requirements: “The license compels an action by the licensee – to make the source code and data available. This is exactly the same type of action required under every copyleft license.”
The CAL does not extend to data: “No rights or obligations are created in any other work.”
The CAL does not restrict usage. It only requires user data to be provided to the extent that it is available. E.g. data may have to be decrypted for a user with a lawful interest, but the CAL is careful to not require disclosure of private keys.
The CAL only compels actions while the operator provides a service. They are free to stop at any time.
Lindberg appreciates the point that users should be able to run the software without reading the license. But with the CAL, the legal load for end users is still zero. Extra burdens are only placed on operators who want to provision the software as a service to others, which is the same scenario where the AGPL applies extra requirements. And anyway: “if you are providing services to others, you have already taken upon you substantial legal liability.”
Lindberg is amazed that Peren's examples boil down to preserving operator's freedom to lock down their user's data. “That freedom is definitely granted under some more permissive licenses, but preserving the rights of users is a core aspect of Free Software, which is the tradition addressed by the CAL.”
Henrik Ingo points out that open source licenses generally grant rights to users and shield them from legal risks. For example, restrictions on DRM are “a great example of protecting user rights”. Peren's objections seem to be problematic primarily with P2P software where end users simultaneously act as operators.
Bruce Perens  agrees that data being hold hostage is a legitimate problem – but it is a social problem. OSI has previously rejected licenses that try to address social issues beyond the software. While OSI-approved licenses sometimes require disclosure of source code, also requiring disclosure of user data would be overreach.
Van Lindberg disagrees. The CAL is not in the same bucket of (non-free) licenses like 996 or JSON “do no evil”. The CAL tries to address an issue (user autonomy) “in the exact same way the GPL addresses the social issue of software freedom.”
Pamela Chestek [1,2,3] summarizes the CAL's relationship to API copyright: Any reimplementation of a CAL-covered API must be offered under the CAL or a compatible license. The CAL does not have a copyleft effect on software that merely uses/consumes the APIs. Assuming API copyright (Oracle v. Google) is overturned, the CAL will not be affected since the CAL is about public performance of APIs and not their reproduction. But without that precedent, how could other implementations be restricted?
Van Lindberg [1,2] confirms that Chestek's analysis is correct, but thinks the chances of API copyright being overturned are rather slim. Even then, CAL hooks into patent rights as a secondary means of enforcing copyleft.
Richard Fontana [1,2] notes that API reimplementations have to be open-sourced when their binaries are distributed or their interfaces are publicly performed. He criticizes the concept of “publicly performing an interface” as unclear, and thinks the relevant clause is written ambiguously. This launches a side discussion about the Oxford Comma.
Richard Fontana asks about the legal situation of API copyright in the EU under the 2012 SAS Institute Inc. v. World Programming Ltd. decision. Carlo Piana explains that the SAS ruling excludes language APIs, programming languages, and file formats from copyrightability in the EU.
Richard Fontana warns that the CAL would be the first license to intentionally expand copyleft to APIs. Henrik Ingo is aghast at Lindberg's explanations: “this couldn't possibly be your intention”. They call some strategic concerns to attention.
Fontana believes that current community consensus is opposed to API copyleft. He sees “a deep-rooted policy against […] restrictive application of interface copyright in free software/open source […] that ought to be read into the OSD and our understanding of software freedom”. This “is supported by widespread hostility in the [community] to the result in Oracle v. Google” and the FSF's policy of opposing API copyrightability. While a license might acknowledge API copyrightability, it should only do so under highly permissive terms and not use it to impose copyleft requirements.
Henrik Ingo hopes the OSI “won't and can't approve of” such copyright-maximalist features. Instead, the open source community has an interest in promoting the view that interface implementations always or typically are fair use. Maybe, many years later APIs do become widely copyrighted. Only then would it be in the interest of the community to wield this power as well.
Ingo also mentions that right now, OSI approval of a license with API copyright elements would be highly undesirable as this could be used by Oracle lawyers as evidence that such views were widely accepted in the industry and open source community.
Van Lindberg understands the strategic objections, but doesn't think “it is an extension to use legal terminology and case law which already presumptively applies to software.”
Bruce Perens asks whether it is in OSI's interest to approve licenses that use public performance rights “for purposes other than requiring publication of the source code”.
There is also the matter of precedent. Perens notes the FSF (although disapproving of software public performance) did something similar with the AGPL, and the OSI eventually approved it. Pamela Chestek thinks this leads to “the understandable complaint that the OSI decisionmaking process can be unpredictable”, especially since no one has claimed that the CAL's API/public-performance aspects would violate the OSD.
Henrik Ingo [1,2] cautions that the “use of public performance in a software license is novel and untested.” This is risky for users. The license doesn't even need public performance rights to work but could use “legal methods that are more boring, but better tested and safer”. So for what reason should the license rely on public performance, other than maximizing its copyright power?
Van Lindberg [1,2] fundamentally disagrees here, and considers public performance key to the CAL. Practically speaking, the AGPL is the only available network copyleft license. But Lindberg found its network copyleft provisions lacking:
Lindberg thinks [1,2] that it's better to use public performance – an established right in copyright law – than to define a unique term like “network interaction”. The use of public performance paired with some other definitions also clarifies corporate compliance.
Henrik Ingo agrees with Lindberg's analysis of the AGPL, and welcomes alternatives. Ingo criticizes the proxy loophole, and its GPL-like mindset that software will be executed as a single process on a single computer which accepts network connections.
However, Ingo vehemently disputes that public performance would be a solution. This is completely uncharted territory, and the CAL fails to bound its implications. Public performance “only adds uncertainty, but little practical value.”
The AGPL protects users by giving explicit and unlimited permission to run the program. Instead of restricting public performance, it uses an awkward construction that compels features of the software but not actions by the operator. Other licenses don't have to use that approach, but simple and clear legal terms help protect users. Perhaps the AGPL could be fixed by merely replacing “network interaction” with “interaction”.
Bruce Perens is confused why, if public performance rights are given, the AGPL went through the trouble of synthesizing a separate public performance-like right.
Pamela Chestek wonders how the CAL would work in the EU, where no equivalent public performance right might exist. Lukas Atkinson points to “communication to the public”, and suggests that the CAL could reference the WIPO treaty where it is defined.
Scott Peterson [1,2] is concerned that the CAL tries to introduce the notion that software interoperation could be the copyright holder's exclusive right. This would attract FUD. Actions that impact the interpretation of copyright law should be considered for their broader impact. Bruce Perens refers to Lindberg's argument that public performance is an existing right for software because software is a literary work.
McCoy Smith links to an article that argues that public performance rights do exist for software, but would not generally apply (Lothar Determann (2015): What Happens in the Cloud: Software as a Service and Copyrights. In: 29 Berkeley Tech. L.J. DOI: https://doi.org/10.15779/Z38DX3N).
Pamela Chestek provides a careful analysis of unclear language in the license.
In April, the License-Discuss mailing list:
The corresponding License-Review summary is online at https://opensource.org/LicenseReview042019 and covers extensive discussion about the Cryptographic Autonomy License.
Chris Webber posts an essay about non-commercial licenses to the list, based on his experience working at Creative Commons.
Webber is “sad to see history repeat itself […] given the [recent] volume of submissions in favor some sort of noncommercial style license” (Note: like SSPL). Whereas Rob Myers joked that NC stands for No Community, Webber argues it represents “‘No Composition’, which is just as much or more of a threat”. Core points:
Defining (non-)commercial use is extremely difficult. See https://wiki.creativecommons.org/wiki/Defining_Noncommercial.
NC is asymmetric. “NC has the kind of appeal that a lottery does: it's very fun to think about participating when you imagine yourself as the recipient.”
NC feels like a minefield. If single NC licenses are already confusing, how would it feel if the whole system switched? For example, would a partially-NC Debian distribution be usable?
Different license users have opposed goals. “Libre Commoners” want to protect the commons, and want everyone to abide by the license. In contrast, “Proprietary Relicensors” want to prevent free riders in order to develop income. This is anti-community.
Webber concludes that “Noncommercial fails in its goals and it fails the community. It sounds nice when you think you'll be the only one on top, but it doesn't work, and it never will.”
Antoine Thomas asks whether a contributor would be able to revoke/remove their contributions from a project, and how this would affect old versions of a project.
Kevin Fleming responds that legitimately provided open source licenses are not revocable, but that a project might honor a request out of courtesy.
Brendan Hickey points out that copyright law may provide special revocation rights, e.g. 17 USC §203. And even without revocation, a contributor could make life difficult for users.
Bruce Perens [1,2,3] affirms that either direction of linking is fine: neither license imposes terms on the software it is linked with. But the LGPL does extend some terms onto the linked work in its entirety, which could be a problem e.g. with proprietary licenses that prohibit reverse engineering. While the Apache-2 patent clause is incompatible with the GPLv2, the LGPL is structured differently.
Bryan Christ notes that the ASF lists the LGPL as incompatible. Bruce Perens explains that the Apache Foundation excludes LGPL software from their own projects because the LGPL affects the larger work, but that the licenses themselves allow linking with each other.
McCoy Smith links to the FSF comment on the Apache license, but notes that it only discusses GPL and not LGPL.