Open Source Initiative

Subscribe to Open Source Initiative feed
Updated: 23 hours 42 min ago

OSI License Discuss and Review: Evolution and Improvement

Fri, 2019-05-24 15:41

The directors of the board of the Open Source Initiative recognize the process for discussion and review of new licenses proposed for approval by the organization can use improvement and would benefit from evolution. In particular, it does not appear as though all points of view on open source licensing are represented in the discussion here. To address this situation we have created a Board Committee for license approval to evaluate responses on-list, appointed more moderators, and will devise a new moderation strategy.

We anticipate that the effort to improve the quality of discussion on the license lists will be an iterative process. This email describes our first step, which is to approach the community and elicit feedback on this approach. We anticipate further steps including a review of tools, but we’re not yet at that stage.

License review vs. License discuss lists

License-review(a) is the email address for submitting a license for which you seek OSI approval following the process at The list is open to the public, so anyone can give their opinion about a license. The OSI License Committee considers the viewpoints expressed on the license-review list in making its license approval recommendation to the OSI Board. Since the purpose of the list is to inform the Committee and the Board, discussion of substantive issues off-list is not recommended. If a license submitter elects to respond to a substantive question submitted to them off-list, the submitter is encouraged to copy the license-review list also on their response after redacting the identity of the person sending the communication.

License-discuss(a) is for general questions about open source licenses and for licenses in early stage development. The list is open to the public and anyone can give feedback. A moderator may decide that a license submitted to license-review isn’t sufficiently developed and will move it to license-discuss for additional work. We recommend that you carry out your license development process on a publicly viewable venue (preferably one where collaboration is also possible) and regularly seek views on license-discuss. Note that agreement on license-discuss does not guarantee agreement on license-review, as the audiences differ.

The board recognizes that the license-review mailing list would benefit from further, more concerted moderation, both to ensure appropriate conversation and to maintain the pace of discussions. This more concerted process will evolve in the following steps:

  • We will develop rules to encourage wider participation. We perceive that some are discouraged from participating because of offensive tone, frequency, or repetitiveness of messages. We will develop moderation standards to address these hurdles.
  • A moderator will also advance the conversation, by following up with the license steward on unanswered questions and ensuring that all topics of interest have been fully fleshed out.
  • We will assure observance of the Code of Conduct for the mailing lists, available at:

Changes to the Website
We have also made a minor change to the language describing the license review process on The page formerly said “Approve, if (a) there is sufficient consensus emerging from community discussion that approval is justified, and (b) the OSI determines that the license conforms to the Open Source Definition and guarantees software freedom." The page now says “Approve if, after taking into consideration community discussion, the OSI determines that the license conforms to the Open Source Definition and guarantees software freedom.”

We have also clarified the timing of the review decision.

License Review Committee
The License Review Committee is an OSI Board committee made up of the following board members, as of May 2019:

Pamela Chestek, chair, pamela.chestek(a)
Elana Hashman, elana.hashman(a)
Chris Lamb, chris.lamb(a)
Simon Phipps, webmink(a)

The License Review Committee will summarize and report the license-review discussions to the Board for the Board’s approval or disapproval of a proposed license. Members of the Committee also serve as moderators for the two mailing lists.

What We’re Asking
If you have not already done so, please subscribe to the license-review and license-discuss lists. And then contribute. More participants will help us ensure that every viewpoint has been heard and considered by the collective, so that the OSI's actions are truly representative of the open source community.


Categories: FLOSS Research

2018 Open Source Initiative Annual Report

Fri, 2019-05-24 15:03

Welcome to the Open Source Initiative’s 2018 annual report. In this year's report you’ll learn about the organization’s activities from the past year, which captures the hard work of employees, contractors, volunteers, and those passionate about open source. I hope this will give you some context on why this work happened and what makes it so important. The Open Source Initiative was started in 1998 by a group of people interested in seeing ethics applied to the creation and distribution of software. This approach was built on a foundation of ideals – a specific philosophy on the rights and responsibilities of software users and creators. More than twenty years later, I am writing as a director of the OSI, which has grown into a robust organization with record numbers of individual and affiliate members, a dedicated all volunteer board, and the incredible support of volunteers and open source enthusiasts around the world.

2018 brought amazing successes for the OSI. We celebrated our 20th anniversary, which took us around the world where we were able to look back on thousands of victories for open source. Every line of code or translation; every piece of documentation and version controlled repository; every successful business, happy user, and committed contributor, continues to shape a movement that has changed the face of technology, business, and community. It was also a year in which Microsoft acquired GitHub, one of the largest distributors of open source licensed code, and IBM purchased open source business giant Red Hat, showing that the companies that built their success around proprietary software see the need for an open source future.

The past year also brought new questions on the validity of the Open Source Definition; the role of open source licensing, and both copyleft extension and enforcement; and individuals and organizations challenging the work of the OSI and the open source community as a whole. This included the legal battle concerning Google’s use of Oracle America’s APIs, and the creation of the Commons Clause, which renders any previously open license no longer OSD-compliant. I view these as challenges we need to meet, and illustrations as to why the the OSI is as important as ever. I am certain that the open source community will rise to the occasion.

It is thanks to your support, interest, and work that the OSI is able to continue our efforts to support software freedom by maintaining the canonical list of open source licenses, providing a home for new projects and community initiatives, and bringing attention to the necessity of open source in the future of computing. The values that drive the OSI have had a demonstrable impact on the world, bringing new approaches to the ethical considerations facing everyone creating and interacting with computing technology and beyond. We see adoption of open source ideals not just in software, but in art, design, publishing, and science. Looking back on 20 years of open source ideology, we see twenty fruitful years of collaboration, contribution, and community that have spawned a philosophy of openness across fields of endeavor. Here’s to 20 more years of open source!

Molly de Blanc
OSI Board President

Categories: FLOSS Research

You're Invited: Celebrating Powering Potential.

Wed, 2019-05-22 19:13

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 to donate and reserve your space at this event.

Asante sana (thank you)!

Categories: FLOSS Research

Open Source Hong Kong Becomes an OSI Affiliate Member

Wed, 2019-05-22 12:25

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 ( together with details for other non-profit and not-for profit organizations on how to join. Individuals can also become Members at

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: ​

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

Categories: FLOSS Research

OSI Board Evolution

Tue, 2019-05-14 10:42

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.

Categories: FLOSS Research

April 2019 License-Review Summary

Mon, 2019-05-06 15:55

In April, the License-Review mailing list saw extensive debate on the Cryptographic Autonomy License, in particular:

  • its user data clause, and how it affects user freedom
  • obligations placed on the software operator
  • API copyright
  • strategic concerns for the OSI
  • public performance rights for software

The corresponding License-Discuss summary is online at and covers discussions about non-commercial licenses, license revocability, and LGPL/Apache compatibility.

Cryptographic Autonomy License

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

Lindberg and Pamela Chestek summarize the core goals of the CAL:

  • that derivative works are handled in a copyleft manner
  • that any software offering the same API is under a compatible license
  • that user data is portable

Note: this summary uses the term “operator” to describe a user who runs the software so that other end users can interact with it.

Summary of Opinions

While the license presents welcome innovation in the network copyleft licensing space, there is also major criticism:

  • operators are subject to unacceptable restrictions regarding user data
  • it is not in OSI's interest to approve an API-copyleft license
  • the novel use of public performance is unclear, untested, unnecessary, and possibly ineffective

Bruce Perens does not recommend approval. Henrik Ingo [1,2] thinks that a “revised, less hazardous version of this license” could eventually get approved.


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.

License Purpose

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.

Lawful Interest in User Data

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

User Freedom and Data

Van Lindberg [1,2] explains why he believes provisions about user data to be necessary. Preserving user freedom is core to Free Software. User data must be protected for that freedom to be effective:

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.

Operator Obligations

Bruce Perens [1,2,3] is concerned that the operator's obligations regarding user data are unclear and excessive:

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

Van Lindberg [1,2,3] counters:

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

Solving Social Issues

Bruce Perens [1] 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.”

API Copyright

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.

Strategic Concerns on API Copyright

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.

Public Performance

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:

  • they do not trigger for unmodified versions
  • they can be gamed by using proxies
  • they are unsuitable to ensure user data access
  • they are unclear in a corporate context

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:

Other points

Pamela Chestek provides a careful analysis of unclear language in the license.

Henrik Ingo is concerned that the anti-DRM provision might not be effective, which leads to some comparisons with the GPLv3 [1,2,3,4].

Categories: FLOSS Research

April 2019 License-Discuss Summary

Mon, 2019-05-06 15:55

In April, the License-Discuss mailing list:

  • talked about non-commercial licensing
  • discussed license revocability
  • answered a question about LGPL/Apache compatibility

The corresponding License-Review summary is online at and covers extensive discussion about the Cryptographic Autonomy License.

International Licenses Redux

As proposed in December, Richard Fontana has updated the “International” license category of the OSI license list.

Non-Commercial doesn't compose

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

  • 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.”

Can a contributor take back open source code?

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.

Compatibility of LGPLv2.1 and Apache 2.0

Bryan Christ [1,2] asks whether Apache-covered software can link with LGPLv2.1 libraries and vice versa. The question is motivated by their incompatible patent clauses.

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.

Categories: FLOSS Research

Join Us In New York City

Thu, 2019-04-18 12:21

OSI members and affiliates are invited to join the OSI Board of Directors, local college and university student groups, and the broader New York City open source community to discuss "Careers in Open Source".

  • Open source jobs, what are they... where are they?
  • Finding and leveraging open source projects to expand your opportunities.
  • What companies and communities are looking for.
  • What you should look for, before accepting the job.
  • Getting the most out of your company to further your open source career.

If you're interested in a career in open source software, have some advice to offer, or just looking to network with peers, we hope you will join us.

Open Source Initiative Spring Meet-up and Mixer
Tuesday, May 7, 2019
6:00 PM to 9:00 PM
566 Fashion Ave Suite 504 · New York, NY

OSI Board Directors have broad backgrounds and experience, working in a variety of roles—Chief Open Source Officer, Chief Information Office, Chief Technology Officer, Open Source Program Manager, Community Manager, Developer, Architect, Engineer, Attorney—for both corporations and communities—Clojure Community, Cloud Native Computing Foundation, Debian Project, Free Software Foundation, Github, Google, Kubernetes Community, Microsoft, One Laptop Per Child, Open edX, Oracle, Python Software Foundation, Red Hat, Salesforce, Sun Microsystems , The Document Foundation, Wikimedia, Zalando... and many, many, more.

Photo credit: "NYCMeetUp.jpg" by Patrick Masson (CC BY 2.0) is a derivative of, "Jobs Board" by Malcolm Tredinnick (CC BY 2.0), via Flickr (

Categories: FLOSS Research

Powering Potential Expands to Peru

Tue, 2019-04-09 16:18
The Nainokanoka Secondary School
in the Ngorongoro District, Tanzania, May 2018

The Open Source Initiative’s first African Affiliate Member, Powering Potential Inc. (PPI), is pleased to announce the launch of their award-winning solar-powered Raspberry Pi computer labs in Peru. The pilot program builds on PPI's successes already enhancing education throughout rural Tanzania, Africa.

Over the past 13 years, PPI has installed 29 solar-powered systems, and 203 computers with servers, in 29 secondary schools across Tanzania. As a result, more than 23,000 students and teachers have been provided with direct access to educational materials and technology-training with minimal impact to the environment.

Neema Lyimo, PPI ICT Manager & installation team at
The Nainokanoka Secondary School, May 2018.

PPI created their Solar-Powered Access to Raspberry Computing (SPARC) installation model using Raspberry Pi computers loaded with an abundance of open source software, such as RACHEL from, and Kolibri from Learning Equality. Educational resources include Khan Academy videos, UNESCO textbooks, and Project Gutenberg literature with health and medical information.

Solar Panel Installation at
The Nainokanoka Secondary School, May 2018

A basic SPARC lab installation consists of five Raspberry Pi computers, two 85-watt panels, three 108Ah batteries, a 15 amp charge controller, a 350 watt inverter, and a lightning arrester system. A SPARC+ installation includes 15 more computers, additional solar panels, six new batteries, and a new charge controller. PPI also uses local vendors to work with school districts to provide solar power and additional equipment.

After installation, school district-selected teachers having a familiarity with technology are given a specialized three week “Train-the-Trainer” course. PPI prepares them to instruct tech literacy classes by learning networking, hardware, word-processing, database, file management, RACHEL maintenance, and email basics.

Project Team Meeting at the San Francisco School
in the Belen District of Iquitos, Peru with (l to r)
Anita Gil Avila, principal; Cledy Grandez Veintemilla,
Director of the Rosa de America private school;
V. Ena Haines, PPI Management Team; and Dana Rensi,
PPI Regional Director, Latin America, July 2017.

Currently, PPI’s pilot project is placing a SPARC lab in the Amazon region at the San Francisco Rio Itaya School, located in a low-income district of Iquitos, Peru. Leading this effort is Dana Rensi, PPI Regional Director, Latin America. She is a recipient of a Fulbright Distinguished Award in Teaching and an Educational Media Specialist in Ashland, Oregon. After being a Fulbright exchange teacher in Iquitos for a year, Rensi began working with V. Ena Haines from the PPI Management Team and is currently scheduled to be on site for five weeks this summer to establish the pilot. If successful, SPARC labs may also be expanded to other villages along the Amazon River.

The geographic isolation of this region in Peru is similar to rural Tanzania in terms of educational hurdles like a high turnover rate for teachers, limited resources and a lack of electricity. Iquitos, for example, is known as the largest city in the world that is accessible only by river or air, which makes technological progress challenging. The pilot installation is on the outskirts of Iquitos in Belén, one of thirteen districts of Peru’s Maynas Province known as “The Floating City.” Other villages along the Amazon River face the same accessibility problems coupled with regular seasonal flooding that has grown worse in some areas from climate change.

An external view of The San Francisco School
during seasonal flooding, March, 2019.

Rensi believes the SPARC lab installation could alter the game entirely for students there. “I came from teenage parents and a poor background. Education was my way out,” she explained during a recent interview. “They [the students] deserve an opportunity to learn no matter what circumstances they are born under or where.”

For this reason and more, PPI is actively seeking volunteers and sponsors for the pilot program in Peru alongside their continued efforts in Tanzania. They will also host a spring fundraiser celebrating their 10-year partnership with the Segal Family Foundation on Wednesday, June 5th from 6 to 8:30 p.m. at 39 West 29th Street in New York City to raise money for a major computer lab upgrade for the 800-student Sazira Secondary School near Lake Victoria in rural Tanzania.

To learn more or find out how you can help, visit

Categories: FLOSS Research

PPT Article

Tue, 2019-04-09 16:17
Image caption

The Open Source Initiative®’s first African Affiliate, Powering Potential Inc. (PPI), is pleased to announce a pilot program expansion in Peru of their award-winning solar-powered Raspberry Pi computer labs already enhancing education throughout rural Tanzania, Africa.

The organization has installed 29 solar-powered systems and 203 computers with servers in 29 secondary schools in Tanzania over the last 13 years. As a result, more than 23,000 students and teachers have been provided with direct access to educational materials and technology training with minimal impact to the environment.

PPI created their Solar-Powered Access to Raspberry Computing (SPARC) installation model using Raspberry Pi computers with an abundance of open source software, such as RACHEL from, Kolibri from Learning Equality. Educational resources include Khan Academy videos, UNESCO textbooks, and Project Gutenberg literature with health and medical information.

A basic SPARC lab installation consists of five Raspberry Pi computers, two 85-watt panels, three 108Ah batteries, a 15 amp charge controller, a 350 watt inverter, and a lightning arrester system. A SPARC+ installation includes 15 more computers, additional solar panels, six new batteries, and a new charge controller. PPI also uses local vendors to work with school districts to provide solar power and additional equipment.

After installation, school district-selected teachers having a familiarity with technology are given a specialized three week “Train-the-Trainer” course. PPI prepares them to instruct tech literacy classes by learning networking, hardware, word-processing, database, file management, RACHEL maintenance, and email basics.

Currently, PPI’s pilot project is placing a SPARC lab in the Amazon region at the San Francisco Rio Itaya School, located in a low-income district of Iquitos, Peru. Leading this effort is Dana Rensi, PPI Regional Director, Latin America. She is a recipient of a Fulbright Distinguished Award in Teaching and an Educational Media Specialist in Ashland, Oregon. After being a Fulbright exchange teacher in Iquitos for a year, Rensi began working with V. Ena Haines from the PPI Management Team and is currently scheduled to be on site for five weeks this summer to establish the pilot. If successful, SPARC labs may also be expanded to other villages along the Amazon River.

The geographic isolation of this region in Peru is similar to rural Tanzania in terms of educational hurdles like a high turnover rate for teachers, limited resources and a lack of electricity. Iquitos, for example, is known as the largest city in the world that is accessible only by river or air, which makes technological progress challenging. The pilot installation is on the outskirts of Iquitos in Belén, one of thirteen districts of Peru’s Maynas Province known as “The Floating City.” Other villages along the Amazon River face the same accessibility problems coupled with regular seasonal flooding that has grown worse in some areas from climate change.

Rensi believes the SPARC lab installation could alter the game entirely for students there. “I came from teenage parents and a poor background. Education was my way out,” she explained during a recent interview. “They [the students] deserve an opportunity to learn no matter what circumstances they are born under or where.”

For this reason and more, PPI is actively seeking volunteers and sponsors for the pilot program in Peru alongside their continued efforts in Tanzania. They will also host a spring fundraiser celebrating their 10-year partnership with the Segal Family Foundation on Wednesday, June 5th from 6 to 8:30 p.m. at 39 West 29th Street in New York City to raise money for a major computer lab upgrade for the 800-student Sazira Secondary School near Lake Victoria in rural Tanzania.

To learn more or find out how you can help, visit

Categories: FLOSS Research

ClearlyDefined Update

Tue, 2019-04-02 09:13

It’s been just over a year since the Open Source Initiative approved the proposal for ClearlyDefined to be a project under its organization. So far the project has successfully built a robust software system in collaboration with lots of folks from the community. We wanted to tell you more about what we’ve built so far and how you can get involved with the project.

What’s ClearlyDefined?

Having clear license data about open source increases everyone’s confidence. Projects want more adoption of their software, and this is built on confidence in knowing how to use it responsibly. Users of open source projects want to feel confident they know how a project is licensed to properly comply with the terms of that license. Organizations and companies building on open source want to feel confident they understand the compliance obligations of all the open source they use.

Enter ClearlyDefined. ClearlyDefined is focused on clarifying data about open source components. Specifically, the initial focus is on three key pieces of data about open source: license, source location, and attribution parties. Clarity on these pieces of data helps everyone know what their obligations are and feel more confident in meeting them.

We have spent the last year as an OSI project building the software to facilitate the project as well as the community around the project.

The project is built around a 3-step process:

  1. Harvest: We are aiming to get as much data about open source components in an automated way as is possible, so first we harvest the interesting data from components using open source tooling. We take open source packages, open them up, run open source scanning tools such as ScanCode, FOSSology, Licensee, etc. on them, and aggregate and summarize the results to produce the best license data we can about the component. That raw and processed data is freely available to our users.
  2. Curate: Even though the tools do a great job at harvesting the interesting data about open source components, in many cases we are still missing data or the data we have is ambiguous. In these cases, ClearlyDefined enables the whole community to come and make changes (“curations”) to the data to improve its quality. These curations are all done in the open, on GitHub, via pull requests, and are meant to be discussed and consensus formed completely transparently.
  3. Upstream: Ultimately collecting and clarifying license data after the fact is a losing battle. For all the data that we curate, we are also building a larger process around upstreaming those changes back to the original projects. Over time, as these changes are integrated upstream, new versions of those components and the open source world as a whole will become more clearly defined.

Can I use ClearlyDefined

Yes! Anyone who’s interested in clear licensing data about open source can use ClearlyDefined. You can go to and browse for your favorite open source component and use it in your open source compliance process. If you see some something missing or off, you can fix it directly on the site and contribute the changes to be reviewed!

While you are there, you can use the site to create a NOTICE file. For example, simply drag and drop your NPM package-lock.json file onto the Definitions page and use the Share button to create and download a NOTICE file in the format of your choice. Check out this short video for a quick example.

In addition, all of these data and capabilities are readily available via REST APIs free to anyone.

If you are a developer who is making open source for your community to use, take a minute to make sure you are following the licensing norms of your community. Having a discoverable license file and clear copyright notices goes a long way to being clearly defined from the beginning.

Can I help ClearlyDefined?

If you are interested in helping us clarify the license data on components we’ve already harvested, we’d love for you to come help us curate. You can learn more about the philosophy as well as how to do your first curation on our docs.

Please let us know if you have questions or want to get further involved, we’d love to hear more from you as we continue to build this project. You can find us on Discord, Twitter, Google Groups, and GitHub.

Categories: FLOSS Research

March 2019 License-Review Summary

Mon, 2019-04-01 07:46

In March, the License-Review mailing list saw the retraction of the SSPL from review, and discussed a set of GPLv3 Additional Terms.

The License-Discuss list (summarized at was far more active. Among other things, it discussed Van Lindberg's upcoming Cryptographic Autonomy License, and saw extensive discussion about the license review process: whether the conduct of the list is appropriate, whether there might be alternatives to using email, and whether PEP-style summaries would help.

License Committee Report

Richard Fontana provides the license committee report:

  • CFSL v1.4: The review period is over. Fontana explains why he thinks the license should be rejected. The OSI board subsequently rejected the license.

  • SSPL v2: MongoDB withdrew the license from review.

  • Twente License: A decision is due 2019-04-05.

Server Side Public License, Version 2

Eliot Horowitz announces that MongoDB retracts the SSPL from the OSI approval process, citing a lack of community support as a reason.

Josh Berkus is disappointed in the withdrawal: “this license poses interesting questions about how copyleft can be extended (or not) and how the OSD's clauses about software packaging need to change in a SaaS world.” Berkus thinks the contents of the license were not appropriately considered, and that too many responses were ad-hominem attacks.

This leads to extensive discussion of the License-Review process (see the License-Discuss summary).

GPL 3+ with Whonix Additional Terms

Patrick Schleizer submits a set of Additional Terms for the GPLv3 for review. These terms try to improve the limitation and disclaimer of warranty in the GPL by incorporating language from the doom3 and micropolis licenses.

This submission raises two governance questions:

  • Should the OSI review Additional Terms for the GPL? This is discussed in a separate section below.
  • Does it make sense for the OSI to review licenses that were not first reviewed by a lawyer? This is discussed on License-Discuss as “the pro-se license constructor”.

Brendan Hickey asks whether Schleizer had talked with the FSF about these improvements. Patrick Schleizer links to such a message.

Schleizer wonders why the GPL allows indemnification terms without containing such terms itself. Richard Fontana mentions this was done solely for Apache 2.0 compatibility, and links to the GPLv3 rationale documents.

Fontana notices that the proposed terms use the word “nonwithstanding” opposite to its intended effect.

Based on the feedback (see also the separate sections), Patrick Schleizer decides to withdraw the license but intends to prepare a revised version.

Should the OSI review GPL Additional Terms?

Patrick Schleizer points out that the GPLv3 Additional Terms mechanism allows “other non-permissive additional terms” to be removed by the user, so that no Additional Terms can render the license non-free. Richard Fontana thinks that if these Additional Terms don't create a new license, then that is a good argument that such Additional Terms are out of scope for OSI review.

Bruce Perens argues [1,2] that adding terms to a license necessarily creates a new license, and points at the recent Commons Clause as an example where simple additions had huge effect. But Schleizer points out that adding Additional Terms is just an exercise of the rights under the GPL, and shouldn't be treated as a modification of the license.

Richard Fontana suggests the OSI shouldn't review Additional Terms, if only to limit license proliferation. Fontana notes the Additional Terms have sometimes be misused, and that review could be valuable for widely used Additional Terms. Fontana points out that the OSI did review two sets of GPLv3 Additional Permissions though they behaved like separate licenses. One is the LGPLv3.

Fontana also suggests that the OSI should defer to the FSF for review of Additional Restrictions. Bruce Perens disagrees [1,2]: The OSI shouldn't give the FSF special status that would exclude some licenses from a review here, in particular not any kind of veto power. However, the OSI should respect the FSF's authority on the GPL and not review licenses that contain “GPL” in their name.

Categories: FLOSS Research

March 2019 License-Discuss Summary

Mon, 2019-04-01 07:46

In March, the License-Discuss mailing list discussed:

  • the Cryptographic Autonomy License
    • its interactions with the GDPR
    • how public performance applies to software
  • the License-Review process
    • views on tone and conduct on the list
    • the list's role in the license review process
    • problems with email, and alternative tools
    • whether a PEP-style process might help
  • whether licenses should be drafted without legal assistance
  • and more

The corresponding License-Review summary is online at and covers the SSPL's retraction from review, as well as discussion of a set of GPLv3 additional terms.

Cryptographic Autonomy License

Van Lindberg requests comments on his Cryptographic Autonomy License (CAL), a network copyleft license motivated by blockchain-based software. He also wrote a blog post explaining the license's background and rationale in detail.

User Data and the GDPR

The CAL has provisions that ensure user's access to their data, which goes in a similar direction as the EU's GDPR – it even references the GDPR in an interpretation clause. The CAL defines a concept of Lawful Interest as the trigger for user access rights.

Henrik Ingo notes that this grants rights to third parties, which is fairly novel and could raise OSD issues. Van Lindberg says these are just third party beneficiaries that receive no rights other than access to the Source and to their own User Data. The data protection in the CAL is not a grant of rights to third parties, but a limitation on the grant to the licensee, similar to the GPLv3's anti-Tivoization clause.

Henrik Ingo [1,2] dives a bit deeper into the CAL ↔ GDPR relationship, and finds CAL User Data to be inconsistent the GDPR personal data concept.

Van Lindberg responds that the CAL and GDPR have different angles: GDPR is primarily concerned about privacy, the CAL primarily about User Autonomy. Lawful Interest is intended to not only capture rights through ownership or the GDPR, but also things like the right to an ebook the user possesses or has licensed. The CAL's User Data concept is more broad than the GDPR's Personal Data. Based on Ingo's feedback, Lindberg updates the wording of the CAL to clarify its relationship with the GDPR.

Public Performance

The CAL triggers some license obligations on “Public Performance”, an aspect of copyright not explicitly discussed by existing Open Source licenses. This is intended to create a network-copyleft license like the AGPL, while being less specific to a medium or technology.

Henrik Ingo [1,2] is a bit put off by this unusual term, similar to the usage of Conveyance in the GPLv3. The CAL also doesn't make it clear what “Publicly Performing an interface” means. Is there any precedent for applying public performance to software? What is an interface? How would this apply to a library API? Ingo is also concerned that public performance could be too broad so that it would cover way more than SaaS style use.

Van Lindberg points out that Public Performance is a well-established term in copyright law, but concedes that its application to software is less well defined. Lindberg intends “interface” to be interpreted broadly, from GUIs to APIs – as long as it can be protected by IP law. This should definitely cover more than just SaaS use. After all, the CAL tries to ensure user autonomy in distributed software systems.

Henrik Ingo thinks the lack of clarity around public performance is a major weakness of the CAL – maybe specific uses should be always allowed, similar to how the GPL gives unlimited permission to run the unmodified program?

Bruce Perens [1,2] isn't sure whether the U.S. copyright law provides a sufficient public performance rights for the CAL to work, in particular whether software is a literary work. Van Lindberg provides numerous references for both US and international law that software is treated as a literary work. (Note: see also the WIPO Copyright Treaty.) It follows that literary works' performance rights must also apply to software.

Other Notes

Henrik Ingo: isn't “Compatible Open Source License” just any OSI-approved license? Van Lindberg [1,2] responds that the CAL defines Open Source licenses as both OSI- and FSF-approved, but that compatibility is determined by the terms of the other license.

The CAL allows a simple LGPL-like exception to be added. Henrik Ingo would prefer if that was a clearly separate license with its own name. Van Lindberg doesn't think this would be a problem, just as there isn't a problem with different GPL exceptions like Classpath.

The CAL significantly expands the reach of copyleft licensing, in particular to public performance. Henrik Ingo thinks this “copyright maximalist” attitude is regrettable, and echoes Bruce Peren's opinion that “Extension of copyright is bad for open source”. Van Lindberg responds that the CAL tries very hard to fit within the established reach of IP law.

Bruce Perens thinks that restricting the license grant to copyright and patents may be too narrow for jurisdictions that recognize additional rights. Perens suggests the license should grant all necessary rights, and only exclude trademarks. Van Lindberg considers broadening the grant.

Bruce Perens [1,2] thinks that the CAL's anti-DRM clause is too narrow as it focuses on specific techniques like cryptographic keys. This could even be understood as a OSD #6 usage restriction. Van Lindberg [1,2] agrees that could be too narrow by itself, but that the license also contains more general anti-DRM clauses. The mention of specific technologies was requested by his client. This isn't so much a user-restrictiction as a kind of anti-Tivoization clause made necessary by the environment for which the license is being developed.

Discussion of License-Review process

In the context of the SSPL's withdrawal from OSI review (see the License-Review summary), Josh Berkus voices disappointment with the License-Review process: instead of legal discussions on the contents of the license, Berkus saw ad-hominem attacks.

[This] was a dramatic failure of the license-review process, and I think shows that this group needs to be reconstituted. […] We need a real process around license approval that isn't “outlast the licensing wonks with the most free time.”

This sparks extensive discussion on whether there was a problem, how the SSPL review should have worked instead, how reviews work, what the problems with email lists are, and whether there might be alternatives (Discourse?).

Views on tone and conduct of the list

McCoy Smith and Richard Fontana [1,2] don't share Berkus' view. Discussions about MongoDB's business model aren't ad-hominem attacks, but closely related to the license's practical effects. Overall, it remained fairly civil. Fontana saw “energetic and serious discussion […] from an unusually wide variety of commenters” and is concerned that curtailing “opinionated, impassioned” discussion “could have the effect of stifling debate and expression.”

Bruce Perens thinks that discussion remained civil, but that he can't respond to some people without it being perceived as a “shouting match”.

Josh Berkus reports that people on the “outside” are baffled and appalled by conduct around the SSPL discussion.

The OSI only has authority to the extent that we are widely regarded as an impartial arbiter of what is and is not open source. It's important. And on the SSPL, we are not widely perceived as fair or impartial.

Richard Fontana points out that License-Review is a public list and shouldn't be conflated with the OSI. And OSI didn't get to be an arbiter on the SSPL because the license was voluntarily withdrawn. However:

Participants on license-review are expected to adhere to the code of conduct, but they are not expected to be neutral or non-opinionated[.]

Rick Moen suspects that the discontent with the list's discussion culture is just “passive-aggressive kickback against License Committee decisions they didn't like”. Richard Fontana [1,2] shares that suspicion: “this sounds to me like a complaint that most of the active participants in the license-review threads on SSPL were hostile to SSPL.”

Perens thinks the problem is that discussion turned repetitious. Lawrence Rosen responds with an 8-point manifesto with his most-repeated points.

Luis Villa [1,2] complains about the volume and quality of discussion. Debate is “only valuable to the extent that they help [and] the current quality and nature of the discussion don't do that very well”:

at some point I checked in […] to see that the thread was literally 100 emails, considered how negative (and often circular) the earlier parts had been, and said "nope, life is too short".

Should the SSPL review have had a different focus?

Where Josh Berkus would like to have seen discussions about copyleft and the OSD in general, Richard Fontana reminds that the license review is not the place for that. The review should only check whether the license “conforms to the Open Source Definition and provides software freedom.” But for Berkus these are not separable: the question of OSD compliance is directly related to the question how far copyleft can and should be extended.

To Berkus' dismay, the recent CopyleftConf didn't see much discussion specifically about the SSPL. McCoy Smith summarizes some points from his talk at the conference which did mention that license and discusses a hypothetical Extreme Copyleft Public License as a though experiment. Smith also points out that the AGPL addresses SaaS business models, so it isn't like the OSI had an anti-SaaS bias. Smith doesn't think the community would have a fundamental objection against extending copyleft beyond AGPLv3.

The list's role in the license-review process

Rick Moen proposes that if the fundamental problem is that License-Review discussions are mistaken for official OSI position, that could be solved if people speaking officially self-identify themselves better.

McCoy Smith sees the following criticisms being made here, and discusses them in more detail:

  1. a few loud voices have undue influence on review decisions
  2. the voices lack variety, or do not reflect the “silent majority”
  3. it is unclear how review decisions take the email discussions into account

Bruce Perens notes about the latter point that the lists are merely advisory, and that the decisions are made by the OSI board in a vote. But there's a lack of transparency in how the board reaches its decisions. Do the board members even read the License-Review list? And how did which director vote? Mike Milinkovich shares his experience as a previous board member: nearly all license approval votes were unanimous. There is also more to the board than voting on licenses, so not every board member should be expected to be a licensing expert.

Richard Fontana [1,2] adds that most license submitters retract their license if it's not clear that it will be approved. This month's vote on the CFSL might have been the first rejection. In that sense, the question isn't whether loud voices have undue influence on the OSI, but what effect they have on the submitter. MongoDB retracted the SSPL just a few days before the board vote, citing a failure to reach a community consensus on the license (which was more than just the license-review discussion).

Ben Hilburn thinks Fontana's distinction between influence on OSI vs influence on license submitters is really important. But while some disagreement is normal and expected, it may also be important to protect the submitter and the debate from negative conduct. Hilburn cautions:

especially for licenses where License-Review recommends rejection, our process and debates really needs to be trusted.

Problems with email, and alternatives

Bruce Perens mentioned discussion turned repetitious. Andrew DeMarsh too thinks the medium of mailing lists makes it easy to discuss the same topics again and again, without being able to easily reference their previous occurrence. This is boring and tiring for list participants. Maybe a better front-end to the mailing lists would help.

Luis Villa [1,2] highlights that the current email-based review process has a number of issues or limitations:

  • limited visibility into the process from the outside
  • too easy to generate vasts amounts of discussion
  • these monthly summaries are too infrequent to guide discussion
  • specific issues are not listed or tracked
  • difficult for outsiders to join constructively, not just with drive-by comments
  • no way to silently signal agreement
  • McCoy Smith adds: archives are difficult to search

Villa suggests that the Discourse software might offer a better platform, but really that any other tool than email would be an improvement. Any tool will have some drawback, but Villa believes Discourse will reduce the barrier of entry to the discussions.

Rick Moen provides a critical summary of his experience with Discourse, for example mentioning the lack of threaded discussion. In contrast, John Sullivan notes that the FSF is happily using Discourse.

Richard Fontana thinks Discourse would be worth trying, although it may be geared to different kinds of discussions. Fontana doesn't think that “new tools will solve what are fundamentally social or political problems.” Villa responds that tools do ease the symptoms.

Rick Moen and Thorsten Glaser [1,2,3] are concerned that using Discourse would require discussion participants to enter a contract with a third party hosting company. Kevin Fleming and Michael Downey responds this wouldn't be the case.

Bruce Perens suggests that at least, the list archive software could be upgraded to something better than Pipermail, which only supports plain text emails.

Responding to an offhand mention of Bugzilla or GitHub, Fontana argues that they would be elitist and keep non-technical people out. “several years ago I entertained the idea that it would be obviously beneficial for license drafting to adopt the preferred tools of developers. […] I see now that […] involved a lot of romanticization of developers and open source development.”

Ben Hilburn agrees with some of the problems around email, but appreciates that email lets the user choose their clients and workflows. Some web-based tools can be integrated with an email-based workflow, which may be desirable.

Would a PEP-style process help?

John Sullivan suggests that the process could be improved without having to change the tools. For example, each license application could be assigned a (volunteer) caretaker who maintains a dossier with the salient points of the discussion. In the end, any process will rely on individuals, and no process will be able to prevent louder voices or individuals with agendas.

Chris Jerdonek draws a comparison to Python's PEP model (Python Enhancement Proposal) where discussion is summarized in a central document. Such a document would also be useful for further reference. Van Lindberg and Ben Hilburn concur.

Bruce Perens and Jerdonek caution that discussion in the PEP process is still mailing-list based with all the drawbacks of the medium. John Sullivan and Jerdonek explain that having the central PEP document helps to keep the discussion on track and makes it easier to join the conversation later.

Bruce Perens is concerned that a PEP-like process might have difficulty achieving consensus for political decisions like license approval. Perens points at the W3C, which used to make consensus decisions until patent policy issues caused insurmountable disagreements. Chris Jerdonek sees PEP more as a documentation thing, not as a consensus-building process. Approval decisions are made externally (Note: compare the role of the OSI board).

Van Lindberg illustrates how the PEP process relates to the review of his CAL license (see below). Here, Lindberg tracks various arguments in a PEP-like blog post.

Who should maintain the PEP summary? Pamela Chestek [1,2] suggests the license submitter could be be tasked with this in order to avoid burdening volunteers. Luis Villa thinks it might be hard for submitters to determine the useful and important arguments that should be covered in the summary. Bruce Perens [1,2] thinks a process editor (or group of editors) can be useful. That might be a job for legal professionals, but not for volunteers on the list who might have a stake in the outcome.

Richard Fontana [1,2] is concerned about possible bias in the summary, both if it is maintained by volunteer editors but especially if the license submitter were responsible. Having a group of editors might help though. Perens thinks submitter-written summaries could work if the summary document has a clear version history, and the submitter is paired with an unaffiliated editor.

Luis Villa [1,2] suggests more collaborative Wiki-ish approaches, or that revisions of the summary would have to be approved by an independent person. Villa is less concerned about bias, more that a useful summary is written at all.

Chris Jerdonek explains that submitter-written summaries can work if bad/biased summary will be cause for a license rejection. Version control etc. is important, though.

The pro-se license constructor

The License-Review list saw a submission of a license that didn't have previous legal review. That raises the question whether it is safe and acceptable for non-lawyers to create and submit licenses.

Bruce Perens [1,2] argues that it is dangerous to promote “Crayon Licenses”. Without legal review, the actual effects of that licenses are unknown. “I thus feel all such things should be rejected, although the reason is entirely outside of the OSD.”

As an example, Perens points to the Jacobsen v Katzer case about the Artistic License, which Larry Wall had drafted pro-se. The case could have set “an absolutely horrid precedent […]: that the license was tantamount to a dedication to the public domain.”

McCoy Smith warns that requiring prior legal review would be a barrier to entry, could cause the review discussion to be dominated by lawyers, and wouldn't guarantee license quality. Perens suggests the barrier could be avoided if the OSI would assign a lawyer like a “public defender”. Henrik Ingo doesn't see an issue with a barrier to entry: There are plenty of approved licenses already available. And the license-review process isn't zero-cost either, the cost is just born by OSI. (Note: and the community!)

Brendan Hickey digs into the purpose of barriers and legal review. Hickey doesn't think that legal review would be suitable to protect end users of the license. And legal probably shouldn't be the first step: “No one should be hiring an attorney to draft a license that will be rejected out of hand.”

Nigel Tzeng [1,2] claims that advice from lawyers would be ignored anyway, which seems to reference the NOSA review. John Cowan points out that a license may be a fine legal document but still fail to conform to the OSD. Tzeng and Bruce Perens [1,2] rehash some of the discussion around the NOSA. After a while that argument flows into the more general discussion about the license-review process, covered above.

Van Lindberg discusses different aspects of license review. On one hand there are policy choices and community considerations, but determining whether a license is legally sound and complies with the OSD is “strongly legally inflected”. Richard Fontana takes issue with that: The OSD is not a legal document but “a statement of philosophy and policy aimed at nonlawyers.” Determining OSD compliance might require lawyer-style thinking, but “a nonlawyer who is steeped in free/open source legal policy […] might be much better qualified to interpret the OSD”. Lawyers might also be biased, for example when they are representing a client. While input on the legal soundness of a license is valuable and requires legal specialists, e.g. in case of the SSPL the policy arguments were ultimately more important.


Thorsten Glaser cross-posts a discussion from the Fedora-Legal list about whether the Open Motif license can be considered open source. Open Motif has an unusual license that restricts its use to “open source” operating systems. Bruce Perens considers this OSD #9 and #10 violations. Florian Weimer points out that RHEL nevertheless ships Open Motif, and he doesn't think this restriction would be problematic.

The GPLv3 allows additional terms that prohibit misrepresentation or decline trademarks. Patrick Schleizer asks: Does that mean the GPL grants such rights by default? John Cowan argues that failure to prohibit something is not permission. Similarly, Bruce Perens points out the lack of affirmative statements that would grant these rights. And the licenses don't have to cover everything in detail: they are embedded in a wider legal context.

End users of open source licenses typically don't explicitly accept the license. Patrick Schleizer [1,2] asks: Doesn't that mean any limitations of liability are ineffective because the end user never waived their rights? Or can warranties be unilaterally disclaimed by the author? Does this differ between common law and civil law jurisdictions? Thorsten Glaser suggests that disclaimers are a condition on the copyright license. Van Lindberg points to the difference between licenses and contracts (Note: which may be an US-centric viewpoint).

Chris Lamb links to the discussion on the Debian bug tracker about the “citationware” requirement of Ole Tange's GNU Parallel utility: the utility prints out a demand to cite the software or to pay the author a lump sum. Jonathon contrasts academic conventions around citation with the wording of that requirement. Bruce Perens notes that in the meanwhile, the citation requirement has been reduced to a non-compulsory request.

Responding to January's discussion about “intimacy”, Florian Weimer adds that AGPL compliance is particularly unproblematic for quine-like programs that can provide their own source code.

Categories: FLOSS Research

Run-off Election Results

Mon, 2019-03-25 10:52

After a tie in the 2019 OSI Board of Directors election between Christine Hall, and Mariatta Wijaya, a run-off election was required. The run-off election ran from March 18th, through March 25th, 2019, resulting in a victory for Christine Hall, by a slim margin of only two votes.

Christine Hall, 96
Mariatta Wijaya, 94

Christine's victory places her into the fourth open Individual Member seat, joining Hong Phuc Dang, Elana Hashman, and Carol Smith. These winners of Individual Member seats join, Pamela Chestek and Molly de Blanc, who were elected by the Affiliate Membership.

Voting in OSI elections is open to all OSI Individual Members, and the (one) representative of each OSI Affiliate Member. Only Individual Members may vote in the election of Individual Member seats. Only Affiliate Member Representatives may vote in the election of Affiliate Member seats. Five Directors of the Board are appointed based on Individual Members' votes (2 year term, maximum 3 consecutive terms). Five Directors of the Board are appointed based on Affiliate Members' votes (3 year term, maximum 2 consecutive terms). One seat on the Board of Directors is dedicated to the General Manager, ex officio, with the term to last the length of employment.

The OSI would like to, again, thank all our members who voted, and especially each of the candidates who steeped forward to run in the election. This year was particularly challenging, and we deeply appreciate the time and energy contributed by the candidates to engage so thoughtfully with the open source community. The OSI elections consistently lure incredible candidates from throughout the community--advocates, contributors, users, and leaders--to support the OSI's work, and advance for the OSI's mission. As a member driven organization, the continued participation of the open source community is vital to our ongoing work to promote and protect open source software, development, and communities.

We would also like to thank our outgoing Board Directors, VM (Vicky) Brasseur, Richard Fontana, Allison Randal, and Italo Vignoli, for their contributions and commitment. We wish them all the best, and hope they will remain involved with the OSI and our work in the years ahead.

Categories: FLOSS Research

New Open Source Initiative Sponsors Emphasize Diverse/Broad Industry Adoption

Fri, 2019-03-22 12:10

Palo Alto, CA - March 22, 2019 – New sponsors, Daily Fantasy Cafe and highlight open source software’s appeal, from traditional business infrastructure to driving innovation.

Today the Open Source Initiative® (OSI), the global non-profit formed to educate about and advocate for the benefits of open source software and communities, is pleased to announce the corporate sponsorship of Daily Fantasy Cafe and The contributions from these diverse companies underscore the broad appeal and applicability of open source software across industries.

Over 20 years of work, the OSI has constantly found adoption of, and contributions to, open source software growing, year over year, as companies realize the benefits and value of collaborative communities of practice. No longer limited to the data centers and development shops of tech-companies, open source software is now pervasive across diverse industries, all seeking to reduce costs, drive innovation, decrease time to market, increase quality, and avoid vendor lock-in.

“The OSI is actively engaged with organizations across government, education, manufacturing, agriculture, entertainment—everywhere.  As new industries emerge, like fantasy sports, they’re choosing to be, ‘open source first,’” says Patrick Masson, General Manager of the Open Source Initiative. “Daily Fantasy Cafe and Lineups really show how broad the appeal is now, and most inspiring, how companies that benefit from open source choose to contribute back. Open source is a collaborative effort, projects need code, community, and cash.”

“Open Source is the foundation of our online businesses, and we are proud to contribute our time, energy and funds to support the cause. We made a cognizant decision to utilize open source as we believe it is a more sustainable and stronger solution moving forward. We are doing what we can to continue the movement” added, Founder, Sam Shefrin.

Corporate sponsorship allows organizations with a clear commitment to open source to support the OSI’s work in promoting and protecting open source software, development, and communities through charitable donations. Funding from sponsors not only ensures the OSI’s continued operations, but also supports vital programs such as the License Review Process, educational initiatives and community driven working groups. Companies interested in giving back in support of the OSI’s mission can learn more on the OSI website.


Founded in 2017, utilizes data science to make sports predictions. We help fans, fantasy sports players and sports bettors make smarter decisions. We provide sports lineups, data and articles at no cost to users. Visit to see more about our mission or email for contact.

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, or email the organization at,

Categories: FLOSS Research

2019 OSI Board Election Results

Sun, 2019-03-17 11:55

OSI elections seat two returning directors, three new directors, with the last seat to be determined through a run-off election.

The OSI recently held our 2019 Board elections to seat six Board Directors, two elected from the affiliate membership, and four from the individual membership. We would like to congratulate, Pamela Chestek (nominated by The Document Foundation), and Molly de Blanc (nominated by the Debian Project) who captured the most votes from OSI Affiliate Members. We would also like to congratulate, Elana Hashman, Hong Phuc Dang and Carol Smith for securing Individual Member seats on the Board. Due to a tie for the fourth Individual Member seat, between Christine Hall and Mariatta Wijaya, a run off election will be required to identify the final OSI Board Director.

The run off election will be held Monday, March 18th (opening at 12:00 a.m. / 00:00) through Monday, March 25th (closing at 12:00 a.m. / 00:00).

The OSI would like to thank all our members who voted, and especially all the candidates who stood for election. Every year the OSI is honored (spoiled really) with an incredible slate of candidates--advocates, contributors, users, and leaders--who step forward from across the open source software community to support the OSI's work, and advance the OSI's mission. As a member driven organization, the active participation of the open source software community is vital to our continued success.

The 2019 elections benefited from our highest turnout of voters to date, with 64% of eligible Affiliate Members voting and 56% of eligible Individual Members casting a ballot. This year's membership drive, which coincides annually with the OSI Board elections, was also our best, welcoming 139 new members.

Affiliate Member Election Results (two open seats)

29    Pamela Chestek (The Document Foundation)
28    Molly de Blanc (Debian Project)

18    Bruce Perens (Open Research Institute)
13    Charles-H. Schulz (Open Information Security Foundation)
12    Olawale Fabiyi (American International University West Africa)
12    Kate Stewart (Linux Foundation)
9    Lior Kaplan (Debian Project)
8    Frank Matranga (Rensselaer Center for Open Source)
7    Rowan Hoskyns-Abrahall (Joomla / Open Source Matters, Inc.)
3    Hugh Douglas-Smith (Joomla / Open Source Matters, Inc.)

Individual Member Election Results (four open seats)

199    Carol Smith
172    Elana Hashman
143    Hong Phuc Dang
104    Christine Hall*
104    Mariatta Wijaya*

92    Duane O'Brien
90    Chris Aniszczyk
81    Van Lindberg
77    Justin Colannino
76    Samson Goddy
64    Luke Faraone
55    Marc Jones
44    Ian Skerrett
33    Brendan Hickey
32    Gustavo G Marmol Alioto
23    Tobie Langel
17    Rakesh Ranjan Jena
16    Dave McAllister

* Run-off election required

Categories: FLOSS Research

Software Freedom Conservancy Becomes an Open Source Initiative Affiliate Member

Thu, 2019-03-14 14:28

Palo Alto, CA - March 14, 2019The Software Freedom Conservancy joins long list of Open Source Initiative Affiliate Members

The Open Source Initiative (OSI), the founding organization of the open source software movement, is excited to announce the Affiliate Membership of the Software Freedom Conservancy. "Conservancy", a public charity, that works to promote, improve, develop, and defend free and open source projects. Conservancy provides a home and infrastructure for projects such as Git, Godot Engine, Inkscape, Outreachy, Samba, and many more. Conservancy's support allows free and open source software developers to focus on what they do best—writing and improving code for the general public—while Conservancy takes care of the projects' needs that do not relate directly to software development and documentation.   "We're excited to participate in the Open Source Initiative's ongoing work to educate users and decision-makers about how licensing and cooperation go hand in hand. By joining as an affiliate member, we affirm our support of collaboration to promote the ideals of software freedom." says Karen Sandler, Software Freedom Conservancy's Executive Director   Critical to both the OSI's and open source projects' success is, as stated in the OSI mission, "building bridges between communities." Both the OSI and Conservancy believe those organisations serving free and open source software communities should seek out ways to support each other—Conservancy's Afffiliate Membership is an excellent example of such collaboration. The OSI Affiliate Member Program is available at no-cost to non-profits, educational institutions, and government agencies that support the OSI's mission to promote and protect open source software. As the steward of the Open Source Definition certifying Open Source Software Licenses, by establishing such certification as the standard for open source software development and distribution, and with the support of our Affiliate Membership, the OSI has become a cornerstone of software freedom.   "Software Freedom Conservancy continues to have a profound effect on the world of free, open source software both through its work sustaining important projects and by engaging more widely on topics of general concern. OSI is delighted to welcome them as an Affiliate and looks forward to working with them to promote software freedom." says Simon Phipps, OSI Board President.   About Conservancy Conservancy, a public charity focused on ethical technology, is the home of nearly fifty member projects dedicated to developing free and open source software.  Conservancy acts as a corporate umbrella, allowing member projects to operate as charitable initiatives without having to independently manage their own corporate structure and administrative services. To learn more about Conservancy, visit, or email at,   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, or email the organization at,
Categories: FLOSS Research

February 2019 License-Review Summary

Mon, 2019-03-04 14:59

In February, the License-Review mailing list discussed:

  • Convertible Free Software License (C-FSL)
  • Twente License
  • Server Side Public License, Version 2 (SSPL v2)
  • Review process, governance, and the OSD

The corresponding License-Discuss summary is online at and covers discussions on how to keep the mailing lists civil, and to what degree the business model of a license submitter should be relevant.

License Committee Report

Richard Fontana provides the license committee report. Currently, three licenses are under review:

  • C-FSL 1.4: A decision is due 2019-02-22.
  • SSPL v2: A decision is due 2019-02-18.
  • Twente License: A decision is due 2019-04-05.
Convertible Free Software License

In response to last month's review, Elmar Stellnberger clarifies that the Original Authors have to decide via consensus or set up their own statutes that cover their decision process.

Rob Landley points out that copyright transfers must be written and signed (at least in the US), so that a license like the C-FSL that tries to circumvent this requirement might not hold up in court.

Twente License

Anand Chowdhary submits his Twente License for approval. It is an MIT-style license, except that it also tries to ensure “European values” and privacy: derivatives of the software may only collect and share personal data with the user's prior consent.

Nigel Tzeng points out that this fails OSD #6 “No Discrimination Against Fields of Endeavor”, while Josh Berkus disagrees. Lawrence Rosen criticizes that the license tries to enforce values: “far more ambitious than software can protect with its mere open source licenses.” Eric Schultz suggests other ways than licenses for open source projects to express values, for example by refusing to support unethical use cases.

Bruce Perens adds a bit of historical background to the OSD: it was written to with anti apartheid licenses in mind that ended up hurting innocent people after the apartheid had ended. (Note: e.g. see Computers and the Apartheid Regime in South Africa)

Josh Berkus criticizes that licenses should not mandate values because the interpretation of these values can be quite subjective – thus making it unclear whether the license has been violated. Anand Chowdhary responds that while expressing certain values is the rationale of this license, the text of the license only contains a specific, unambiguous condition.

Carlo Piana [1,2] argues that it is not the job of licenses to ensure compliance with legal obligations: “the entire concept is wrong” and fails to account for changing laws over time.

Lukas Atkinson argues that data protection is not inherent in a software but depends on how the software is used. Therefore, a copyright license doesn't offer a suitable enforcement tool. And while the license seems to emulate the GDPR, it is both more narrow and more restrictive. Atkinson suggests that it might be a better approach to combine the MIT-like attribution requirement with a GDPR-like transparency requirement, but without directly restricting the use of the software. Carlo Piana thinks this is a good idea in principle, but that correctly implementing such a requirement in a license would be rather difficult. In response to this, Anand Chowdhary clarifies their goals and starts drafting a transparency clause.

Server Side Public License, Version 2

Eliot Horowitz (MongoDB) responds to criticism of the SSPL's section 13, and provides some clarifications. Horowitz proposes a rewritten section that explicitly defines “Software as a Service” as “enabling a user to interact with software remotely through a computer network.”

Bruce Perens appreciates this clarification, but notes that this definition was not subject to major objections. Instead, Perens suggest removing the concept of “Service Source Code” in favour of sticking with the AGPL's Corresponding Source concept. Perens summarizes his objections: that the Service Source Code concept attempts to encumber unrelated programs thus running into OSD #9, and that section 13 as written restricts fields of endeavour such as offering the software as a service, thus running into OSD #6.

I don't see how you can change this while keeping the intent of your license […] subsequent alterations to the license text have not substantially addressed [these objections].

Similarly, Brendan Hickey finds that the central objections have not been addressed, though Hickey also points out the SSPL's use of “value” and “primary purpose” as problematic. “What's so special about these claims versus others? Simply, a license that doesn't conform to the OSD must be rejected. As long as these problems are unresolved everything else – like the definition of SAAS – is just window dressing.” In contrast, Kyle Mitchell finds that Horowitz' clarifications address the objections he had.

Review process, governance, and the OSD

In the context of the SSPL review, Kyle Mitchell criticizes the OSI's license review process, in particular the weight given to Peren's voice. “I've lost confidence in this body's ability to make rigorous decisions, or even facilitate focused debate, on any remotely interesting new copyleft license.” Rick Moen quips: “I think Bruce is permitted to be correct and listened to, despite the admitted difficulty of his having credibility on the subject.”

Perens responds to Mitchell that he founds his SSPL criticism solely on the question whether the license can be Open Source: “This is not an issue of my being a honcho, but of clearly stated rules in the OSD that the license intent very obviously came into conflict with.” Perens is also happy to engage with new licensing ideas when they don't purport to be Open Source. In turn, Mitchell disagrees that the OSD would be so clear. “If OSD 6 banned any kind of [discrimination], GPLv2 discriminated against proprietary software makers.” “There should be a new, crips, clear rule on open source copyleft scope. OSD 9 isn't it.” Perens responds to individual points in Mitchell's message. “Free Software and Open Source drew a line in the sand, gave it a brand, and have defended that line. There will always be attempts to push it elsewhere, and they will always be resisted.”

Lawrence Rosen shares some of Mitchell's concerns regarding the scopes of the OSD versus SSPL, but thinks the discussion on these should be separated from the SSPL. In particular:

  • What components or other aspects of server applications are potentially subject to open source copyleft?

  • Is “corresponding source” more than only the Original Work and Derivative Works as defined in copyright law? How much more?

There's also some debate about the “silent majority” who do not participate on the license-review list. Do they approve of everything and would speak up otherwise? Or are they absent because they disagree with the review? Bruce Perens suggests a third option:

Very few people in the world want to be involved with license approval. Not even a majority of OSI directors. That's why what happens on this list is important. They're all trusting us to get it right.

Note: If you'd like to participate on the lists, head over to for information on how to subscribe.

Categories: FLOSS Research

February 2019 License-Discuss Summary

Mon, 2019-03-04 14:59

In February, the License-Discuss mailing list discussed how to keep the mailing lists civil and to what degree the business model of a license submitter should be relevant.

The corresponding License-Review summary is online at and covers reviews of the C-FSL, SSPL, the Twente License, plus some discussion about the review process, governance, and the OSD.

Encouraging discussion around the technicalities of licensing

Martijn Verburg offers their outside view of the License-Review list: while the license commentary may be insightful, some remarks seem to get ad hominem or hostile which is not a good look.

Many list members thank Verburg for bringing this up. Simon Phipps confirms that “Comments aimed at the submitter alone, such as about their business, business model or investors, are rarely appropriate.”

McCoy Smith couldn't find a a Code of Conduct for the mailing list. Phipps points to CoC for the licensing mailing lists, “but it's clearly due for some maintenance.”

There was some discussion to which degree license reviews should touch on the submitter's business model. For example, Lawrence Rosen thinks the SSPL cannot be separated from MongoDB's business model. In contrast, McCoy Smith advocates for focussing reviews strictly on the license and points to his talk at CopyleftConf.

Richard Fontana disagrees with Smith: “the business model of the license submitter can be a material consideration” when assessing a license. “Just the submitter's business model, or the business models of any possible user of the license?”, Phipps asks. Fontana responds attention should be focussed on “Just the submitter's, […] because it may be too hard to think about all the possible ways an approved license might be gamed […] by a future licensor”, John Sullivan doesn't think that the view should be artificially narrowed but that “the interpretations of the license author will carry weight, and the business model is an embodiment of those interpretations.” Marc Jones recasts the question as “license reusability”, but the point of this is not quite clear to me.

Brendan Hickey also disagrees with Smith's suggestion. It's really difficult to lay down bright lines what topics may or may not be considered. While the review should assume the license was drafted in good faith, context is important and the submitter's motives shouldn't be disregarded: “Charity is not a commitment to naiveté.” Smith rebukes some individual points in Hickey's argument.


In January, Bruce Perens opined that any extensions of copyright are bad for Open Source. Russel McOrmond connects this with an article they wrote in 2008 about possible unintended consequences of the AGPL, in particular that network copyleft would harm the free software community.

Categories: FLOSS Research

The Value of Open Source Software In Higher Education

Tue, 2019-02-26 15:39

Contributed by OSI Affiliate Member Apereo Foundation's Board of Directors

Apereo was founded around a mission to support educational institutions “…collaborate to foster, develop, and sustain open technologies and innovation to support learning, teaching, and research". Open source software is at the heart of what Apereo is and does. Why do we believe open source is so important for education?

Cost and Capacity. Many institutions are drawn to open source software because it is free from licensing costs. In times of spiraling student debt, that’s an understandable reaction. Open source software isn’t free from cost, of course. But costs incurred – either in-house or hired implementation specialists – develop and enhance institutional capacity and capability. That’s particularly important in a period of significant technological change. Institutions that invest in open source software as part of an institutional mixed software economy that includes open source retain the flexibility to adapt to changed circumstances and challenges. Institutions that rely solely on commercial-proprietary vendors – whether on-premises or cloud-based - effectively outsource their IT strategy and reduce their capability to deal with change with agility.

Institutional Flexibility. Open source software is flexible and adaptable at an institutional level. An open source community is a place to share innovation. Sharing, encouraging adoption and further contribution helps to ensure that an institution doesn’t carry the future cost of supporting innovation alone.

When considering systems facing a large number of diverse constituents, open source flexibility is a big advantage in ensuring user satisfaction. The NYU Experience, as it has evolved with Sakai, is a good example of an institution using open source software to innovate, improve, and meet user needs. NYU’s improvement cycle has five stages -

  • Consulting users through detailed surveys
  • Assessing the priority of requests
  • Building adaptations and solutions
  • Integrating these with broader Sakai community developments outside NYU
  • Deploying a solution that more closely meets user needs

The way NYU manages this process, and integrates with broader Sakai community development, translates into minimum future maintenance overhead. NYU’s LMS Faculty satisfaction figures speak for themselves. Not only has user dissatisfaction shrunk significantly, but positive satisfaction has risen well past the EDUCAUSE recorded US average. NYU can only do this because open source code underpins the realisation of a vision of continuous improvement.


Money and mission. The investment NYU makes - together with other members of the Sakai community - goes to directly benefit the development of customer satisfaction and product enhancement. In contrast, a recent .edu IPO revealed a major commercial entity spent just 23.5% of revenue on product improvement, with 24.89% on admin and 51.61% on marketing. What’s a better use of higher ed resources?

Support. Open source software offers further flexibility. It can be supported in-house, with the additional resource of an active community of problem solvers. It can be supported by commercial integration specialists, or by hosting providers. Institutions are free to move between the three models – or mix them – to meet their needs, budget and context. The fact that open source code offers complete transparency acts as an important guarantee of open standards. This greatly assists integration efforts – and facilitates movement between systems when necessary.

Dimensions of Adaptability. As we move beyond the “one size fits all LMS” and explore more flexible environments that meet the needs of different disciplines, teaching styles and learners, open source systems are emerging as critical elements underpinning innovation. Tools, environments and frameworks under the Apereo umbrella include -

Xerte, which originated at the University of Nottingham, enables authoring rich interactive and accessible content that will play in any learning environment.

Sakai a mature and robust environment with second to none support for IMS global LTI.

Tsugi - in Apereo incubation - is a framework for tool development and pluggability. The University of Dayton have used Tsugi in conjunction with Sakai to plug dozens of niche tools into their learning environment.

OpenEQUELLA, a digital repository, is widely used to store, curate and retrieve learning materials. Some schools, including Canberra Institute of Technology, use OpenEQUELLA as a replacement filestore for their learning management system/virtual learning environment.

Opencast, a lecture capture, media management and distribution platform is used at very significant scale by the University of Manchester. The Opencast community is equipping it’s player technology with support for learning analytics data streams.

Karuta, a next-generation portfolio solution, originated in work by HEC Montreal, Kyoto University and the University of Grenoble Engineering. Karuta is currently attracting significant interest in the Francophone world.

That’s a small subset of Apereo software communities. There are more details over at -

The ability to innovate is clearly dependent on the vision and capacity of the innovators, but by allowing access to open source code around which to build, OSS provides a starting base point for innovation. Open source communities act to stimulate and pool innovation and the exchange of best practice. Open source software helps to close the “innovation gap” between the emerging needs of practitioners and institutions and distant and opaque commercial proprietary software development. The innovation gap is particularly important in mission related areas. Those who are closest to the needs of learning, teaching and research (including students) should be closely involved in developing the solutions they use.

Curriculum connections. Use of open source software in several major industries - including the social media giants - is widespread to the point of ubiquity. A survey of Fortune 2000 companies in 2018 found -

  • 93% of companies use open source for non-commercial or internal reasons
  • 79% use open source for commercial reasons
  • 69% contribute code upstream
  • 60% have created their own open source projects

Establishing curricular connections between in house open source expertise and the generation about to enter the 21st century workplace is a ‘win’ for all concerned. As data handling, computational skills and algorithmic literacy become integrated with an increasing number of subject areas, open source software offers the possibility of developing deep and significant understanding. Such engagement also offers the potential for students to become co-creators of their own learning.

The future. Existing software categories, such as the LMS, are neither immutable nor the apogee of technology enhanced learning. Three years ago, EDUCAUSE consulted broadly around what they term the “Next Generation Digital Learning Environment”. The EDUCAUSE conception of the NGDLE demonstrates an emerging consensus about the direction of software to support teaching and learning. The NGDLE contains significant challenges in terms of realization, but we are also entitled to ask – in three years, why aren’t we closer? Could the closed nature of commercial proprietary software and its failure to innovate towards identified community needs be bound up in this failure?

Affinity. Open source software and higher education both support the “common good”. There is a natural affinity and close correlation between the philosophy underpinning higher education and open source software. More practically, open source software offers a future where that vision of more flexible and responsive systems supporting the academic mission can be collaboratively realised. Join us to help realise them.


Categories: FLOSS Research