Open Source Initiative

Subscribe to Open Source Initiative feed
Updated: 4 hours 47 min ago

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 Lineups.com 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 Lineups.com. 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, Lineups.com 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.

About Lineups.com

Founded in 2017, Lineups.com 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 https://www.lineups.com to see more about our mission or email info@lineups.com 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 https://opensource.org, or email the organization at, contact@opensource.org.

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 https://sfconservancy.org/, or email at, info@sfconservancy.org.   About The Open Source Initiative Founded in 1998, the Open Source Initiative (OSI) protects and promotes open source software, development and communities, championing software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition, and preventing abuse of the ideals and ethos inherent to the open source movement. The OSI is a public charity with global vision based in California. For more information about the OSI, please see https://opensource.org, or email the organization at, contact@opensource.org.
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 https://opensource.org/LicenseDiscuss022019 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 https://opensource.org/lists 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 https://opensource.org/LicenseReview022019 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.

Leftovers

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 -  http://bit.ly/ApereoCommunities

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

Affirmation of the Open Source Definition

Tue, 2019-02-05 11:07

PALO ALTO, Calif. - Feb. 5, 2019 -- In 1799 the kilogram was defined as the mass of a litre of water. In 1889, metal cylinders of the precise identical mass were created as reference objects.

In the hundreds of years since, the physical nature of the metal caused those cylinders no longer to reflect the identical mass as defined. In order to ensure the integrity of a vital unit of measurement, the kilogram was redefined as the same mass but simply expressed in terms of fundamental and invariable physical constants.

Without this single, standard definition of this or other fundamental units, commerce as we know it would not be possible. There is no trust in a world where anyone can invent their own definition for units, items, and concepts on which others rely, and without trust there is no community, no collaboration, and no cultural or technological development.

In exactly the same way, the term "open source software" was coined in 1998 as software that provides a set of precise freedoms and benefits, including but not limited to the freedoms to run, study, redistribute, and improve the software on which you rely . These benefits are codified in the Open Source Definition (OSD), which is based on the Debian Free Software Guidelines. The Open Source Initiative, its members, affiliates, and sponsors, promote and protect this fundamental definition through software license review and approval.

Without this single, standard definition of "open source," software development as we know it would not be possible. There is no trust in a world where anyone can invent their own definition for open source, and without trust there is no community, no collaboration, and no innovation.

Recently there have been efforts to undermine the integrity of open source by claiming there is no need for a single, authoritative definition. These efforts are motivated by the interests of a few rather than the benefit of all, and are at odds with the principles that have so demonstratively served us  well in the past decades. If allowed to continue, these efforts will erode the trust of both users and contributors, and hinder the innovation that is enabled by open source software, just as surely as having multiple definitions of a kilogram would erode and undermine commerce.

We, the undersigned, affirm our commitment to the Open Source Definition. We acknowledge its importance to the development of the software on which we rely to operate our businesses and organisations. We pledge to guard and maintain the Open Source Definition and we recognize the Open Source Initiative as the steward of the Open Source Definition.

Open Source Initiative, Board of Directors

American International University West Africa, The Gambia
Apereo Foundation
Association Francophone des Utilisateurs de Logiciels Libres
Associazione LibreItalia
BigBlueButton, Inc.
California Association of Voting Officials
Creative Commons
Debian Project
DemocracyLab
Drupal Association
Eclipse Foundation
Journal of Open Source Software
Kaiyuanshe
KDE e.V.
Linux Australia, Inc.
Linux Professional Institute
LinuxFest Northwest
Mozilla Foundation
New Zealand Open Source Society
Odoo Community Association
Open Source Matters, Inc. (Joomla)
Open Source Sweden
OpenProject GmbH
OW2 Consortium
Plone Foundation
Powering Potential
Puerto Rico Python Interest Group
Python Software Foundation
Rensselaer Center for Open Source
Snowdrift.coop
sysarmy
The Document Foundation
The Perl Foundation
Tiki Wiki CMS Groupware
TYPO3 Association
Xerte Project

Categories: FLOSS Research

January 2019 License-Review Summary

Mon, 2019-02-04 16:57

In January, the License-Review mailing list discussed:

  • the new license review process
  • Server Side Public License, Version 2 (SSPL v2)
  • Convertible Free Software License, Version 1.3 (C-FSL v1.3)
    • What are the problems with Original Authors?
    • How is the C-FSL different from CLAs or permissive licenses?
    • Why is the publication requirement a problem?
    • Can the C-FSL be OSI-approved?
  • Convertible Free Software License, Version 1.4 (C-FSL v1.4)

The corresponding License-Discuss summary is online at https://opensource.org/LicenseDiscuss012019 and covers discussion on the opensource.dev info site, Open Data, “intimacy” in open source licenses, relicensing and maintainer–community dynamics, and VanL's upcoming license.

License Committee Report

Richard Fontana provides the license committee report [1,2].

The new license review process has been adopted, and will apply for ongoing reviews. Simon Phipps clarifies that the OSI Board will handle review decisions like any other board vote, but taking into account the advice and discussion on the license-review mailing list Phipps confirms that this new process means that “Stallman's four freedoms are an assumed precondition for evaluation.” OSI-approved licenses should be fine for general use, and ensure a level playing field.

SSPL v2: the discussion is ongoing. The board will decide on 2019-02-18.

C-FSL v1.3: approval of the previous version was withheld, and version 1.3 was submitted. The board will decide on 2019-02-18.

Bruce Perens suggests that both licenses should be rejected: The new version of the C-FSL just seems to package the same discriminatory terms in different words. And the SSPL only receives comments on how it conflicts with Open Source principles or comments that argue that such a license is necessary, without proposing a solution to these conflicts.

Server Side Public License, Version 2

Eliot Horowitz (MongoDB) announces that MongoDB is working towards a new revision of the SSPL. Horowitz clarifies that the focus on “service” is intended to cover multiple facets: not only offering a network service, but also offering services that derive their value from the software or services that provide the functionality of the software. Horowitz claims that the source disclosure requirements are narrower under the SSPL (only when offering the software as a service) than under the AGPL (when users interact with modified versions of the software) because he considers it to be easier to determine the purpose of the use of the software than to determine whether the software has been modified (Note: hmm).

Gil Yehuda appreciates the clarifications of the SSPL over the AGPL, but notes that the SSPL only seems to be OSD-compliant for most users – but not all.

Bruce Perens sees the SSPL as incompatible with OSD #9 “License must not restrict other software” because the SSPL requires the disclosure of software that is aggregated with but not derivative or part of the SSPL-covered software. “I wrote #9 into the OSD to prohibit exactly this sort of conduct. Exactly. The text is really clear.”

Horowitz asserts that the goal of the SSPL is not to prevent commercial use in order to sell enterprise licenses, merely to protect “innovative open source software” (read: MongoDB's own hosted offering) from exploitation (read: competition) by large cloud vendors. John Cowan finds this confusing: why would MongoDB be fine with users installing MongoDB on servers in the cloud, but not with cloud providers offering managed services? The cloud provider would get paid either way. Vadim Tkachenko views MongoDB's stance as hypocritical: they want to suppress competitors to their business model, while still painting themselves as an Open Source company because that drove adoption of MongoDB by developers.

Rob Landley notes that license or governance changes often result in more successful forks, as in the case of XFree86/X.Org. MongoDB's license change to the SSPL has already caused it to be dropped by Linux distros, and compatible replacements (e.g. from Amazon) or maintained forks (e.g. from Percona) are already available. “OSI aside, the community seems to have pretty clearly spoken.” However, Nigel Tzeng cautions that this is a matter of long-term investment. MongoDB will certainly continue to invest into their core product, whereas forks might not see comparable effort.

Carlo Piana insists that the review should focus on the legally binding license text, not on MongoDB's intention. However, this also means that Horowitz' clarifications are irrelevant unless they become part of the license.

Convertible Free Software License, Version 1.3

Elmar Stellnberger submits a completely rewritten version of the license [1,2]. The goal of this license is that maintainers of an open source project are free to change the license of the project, and can integrate any downstream modifications. Without the C-FSL, the project license could only be changed if the project uses a permissive license, if all copyright holders consent, or if all contributors signed a Contributor License Agreement (CLA) – but none of these ensure that downstream modifications are available under the same license. The C-FSL is therefore a copyleft license where contributors give designated “Original Authors” special relicensing rights.

The idea of this license in general and the rewrite for the third version specifically are viewed quite critically on the mailing list.

Carlo Piana recognizes “substantial effort to overcome most of the criticisms to the original version” but is frustrated with the apparent lack of understanding Stellnberger shows for this criticisms. Bruce Perens isn't satisfied at all: “When you request a “rewrite” of a license with a fundamental goal that is in conflict with the OSD, you are likely to get a rewritten license with the same problem as the original. And in this case we did.” Similarly, Brendan Hickey finds that the rewrite “doesn't address fundamental objections raised in the last version. […] There's nothing wrong with proprietary software, just don't call it open source.”

There are three major criticisms of the C-FSL:

1) The special role of Original Authors is discriminatory, as argued by Brendan Hickey: “This is conceptually incompatible with the OSD. Any license that implements this is non-free.”

2) The C-FSL is trying to do copyright assignments in disguise.

3) The license imposes an onerous publication requirement for all changes.

Carlo Piana provides an excellent analysis of the biggest problems with the license.

What are the problems with Original Authors?

Under the C-FSL, Original Authors can be appointed to act as the “effective copyright holders“. These can relicense the software by themselves, without having to acquire individual consent from all copyright holders – contributors have given implicit consent in advance. It is not clear what the rules of consensus among Original Authors are (majority vote?).

These Original Authors are just a subset of all copyright holders, which disenfranchises other contributors. Simon Phipps points out that while there is precedent for asymmetric licenses, each half must still effectively be an OSI-approved license. (Note: Asymmetry was debated but ultimately removed during the approval process of the Upstream Compatibility License in 2016–2017.)

Forks can assign their own Original Authors only if the fork is at least 65% different – a very high threshold. This deprives the forked project of their rights in the code. Stellnberger's intention for this hurdle is that it prevents two concurrent groups of Original Authors.

But the freedom to fork is exactly what Open Source is about! Rob Landley writes a long email which traces through xfree96 and early Linux history, highlighting the differences between project forks and community forks and why a fork can be good for the community: “what this license is trying to do with its “original developers” nonsense does not match reality, even a little. […] It is conceptually broken.” Bruce Perens agrees: the C-FSL not only violates the OSD, it is also bad for the community. A separate thread ensues with numerous examples of relicensing, forks, and maintainer–community dynamics (Note: covered in the License-Discuss summary).

The Original Authors can always appoint more Original Authors. But this doesn't guarantee that the Original Authors hold a significant copyright stake in the work. The concept of authorship also gets muddy when code from another project is included. Brendan Hickey notices that this allows the 65% rule to be circumvented, for example by including a huge third party library, or by including only a tiny part of the C-FSL covered code.

Rob Landley points out that licenses don't determine who the copyright holder is, but what the copyright holders allow other people to do. This spawns a small discussion about the role of joint authorship in Open Source [1,2].

How is the C-FSL different from CLAs or permissive licenses?

The goal of this license is that the maintainers can easily relicense the project, without having to deal with CLAs. If the CLAs and the C-FSL are criticized so much why not also permissive licenses, Stellnberger asks?

Permissive licenses effectively allow anyone to relicense the code, whereas the C-FSL assigns this right to the Original Authors (see above criticism).

Carlo Piana notes that contributors can refuse to sign a CLA in which case their changes cannot be merged into the upstream project, but contributors cannot refuse the C-FSL because it applies implicitly as soon as the changes are made. Brendan Hickey [1,2] points out that Project Harmony can be used for standard-ish CLA templates. In any way, allowing a maintainer team to do arbitrary relicensing is not a problem for Open Source to solve.

Note: a further problem with allowing arbitrary relicensing is that contributors do not know up front which rights may be licensed. Contributors must therefore assume that they retain no rights except those explicitly licensed back through the C-FSL. A CLA at least explicitly enumerates which rights are licensed, and says whether they are licensed exclusively. The C-FSL's implicitness might be a problem if a jurisdiction's copyright laws require a specific contract form for these right transfers.

Why is the publication requirement a problem?

Carlo Piana notices that any changes to a C-FSL covered work must be published within a month, even incomplete or buggy changes. This violates the author's right to decide whether to publish at all.

This is APPROPRIATION, plain and simple. So any changes I make, whether or not released to the public, are contributed with an equivalent of an assignment, granting rights over the derivative code, including the copyright of the developer, which are not available to the developer and there is no way to avoid it.

Elmar Stellnberger responds that the publication requirement for buggy changes was not intentional. And isn't such a publication obligation similar to the Vim or Affero licenses? (Note: Nope. While Vim has a publication requirement, it also has an alternative GPLv2+ relicensing clause. And the AGPL doesn't require publication except when the software is conveyed or made available to users over a network.)

Nigel Tzeng sees this publication requirement as a deal killer. All changes would have to be in public repositories. And because it would be extremely easy to be non-compliant, the C-FSL is a license trap.

Can the C-FSL be OSI-approved?

Brendan Hickey points out that the Debian Project has long argued that the C-FSL violates the DFSG, so OSI will hopefully not decide differently.

Carlo Piana suggests that the license might become OSD-compliant if the CLA-like aspect only triggers on contribution to the upstream project, not as soon as the code is modified. “I expected something in this direction with the new license, conversely I only see stubborn rewording that makes it more hard to lay persons to spot how the license in practice work.” Elmar Stellnberger rejects this suggestion: “That would lead the whole clause of original authors ad absurdum” and make it too easy for other people to relicense the project.

Convertible Free Software License, Version 1.4

Elmar Stellnberger submits the next revision of the C-FSL. Lukas Atkinson summarizes the changes: minor clarifications and a closed loophole. But no progress regarding the fundamental criticism has been made, so that further review seems pointless.

Categories: FLOSS Research

January 2019 License-Discuss Summary

Mon, 2019-02-04 16:57

In January, the License-Discuss mailing list discussed:

  • the opensource.dev info site
  • Open Data
  • “intimacy” in Open Source licenses
    • process and interface boundaries
    • corresponding Source
    • is it a problem that the FSF introduced a new word?
    • making sense of the law, and bright lines
    • licensor expectations
  • relicensing and maintainer–community dynamics
  • VanL's upcoming copyleft license

The corresponding License-Review summary is online at https://opensource.org/LicenseReview012019 and covers discussion on the SSPL v2 and the C-FSL.

opensource.dev

Chris DiBona (Google) announces https://opensource.dev/, an info page about Open Source by Google. It seems to be aligned with OSI interpretation and receives general praise and appreciation from the list. Christopher Sean Morrison lauds the good collection of resources about Open Source, and notes how accessible it is to new developers and non-developers as well.

The opensource.dev site links to the OSI's licenses page. There is some discussion whether the EPL and CDDL should really be on that list of popular licenses. While no one disagrees on the CDDL, Mike Milinkovich (Eclipse Foundation) points out that the many Eclipse projects are a strong community that uses the EPL – though some might disagree that a foundation is a community.

Open Data

Christopher Sean Morrison announces that the US has signed a new open data law into effect. Gil Yehuda wonders whether there is a widely accepted definition of Open Data, similar to the OSD and the Four Freedoms for software? Sander van der Waal (Open Knowledge Foundation, OKFN) points to the OKFN's https://opendefinition.org which was inspired by the OSD. The OKFN also offers a license review process for Open Data licenses. However, version 4 of the Creative Commons licenses might make special Open Data licenses unnecessary. (Note: for example, CCv4 also considers database rights.)

AFL "attribution notice"

Antoine Thomas (PrestaShop) asks for clarification how derivative works should provide attribution under the Academic Free License. No one responded on-list :(

Intimacy in Open Source

Gil Yehuda asks what the (A)GPLv3 means by “intimate data communication”. For example, would a database client/driver not have intimate communication with its database server? Or are they completely separate works? Lawrence Rosen also raises the issue how this interacts with API copyrightability and what this means for network copyleft like AGPL and SSPL. Extensive discussion ensues.

Process and interface boundaries

John Cowan argues that communication is intimate when data structures are shared in memory. Shelling out would not count as intimate because that uses the software's standard interface. (Note: while the conclusion seems correct, the GPL defines Standard Interfaces more narrowly.) Luis Villa agrees with Cowan and even suggests that communication via a well defined interface cannot be intimate.

Nicholas Weinstock thinks that this viewpoint makes sense and can explain why/when downstream users are subject to the (A)GPL, but wonders whether this would go against the “Torvalds Exception” (a statement that user space programs are not derivative of the Linux kernel). Bruce Perens confirms Weinstock's understanding that copyleft affects downstream use, but notes that the Torvalds Exception isn't so much an exception as a clarification of what the GPL is saying anyway. Perens cautions that if APIs are indeed copyrightable (cf Oracle v Google) then dynamic linking does not insulate downstream users from GPL-covered code.

In general, Perens subscribes to the idea that intimacy does not apply when using a public API: “The programmers intended for you to use the API to connect to other programs” and “Intimacy requires intrusion into the internals of the program beyond the API published for programmers to use.” But with API copyrightability, “intimacy is not required for the creation of a derivative work” and a software would be derivative “even if it only uses the library's published API.” Weinstock points out that the distinction between internal and external APIs is not clear, for example when a fork could expose previously-internal APIs.

Corresponding Source

Lukas Atkinson notes that the GPL only talks about intimate communication as an example for what must be included in the software's Corresponding Source. The Corresponding Source must include everything necessary to build, install, and run the software, i.e. any upstream dependencies.

Talking about intimate communication or different kinds of linking is pointless when looking at downstream usage of the software: the GPL does not and cannot define what counts as a derivative work, because that is the job of copyright law.

Nicholas Weinstock asks whether this means that a GPL application is forbidden from relying on incompatibly-licensed libraries, and whether non-necessary libraries would not be intimate. Bruce Perens agrees with Atkinson's understanding of Corresponding Source and confirms that dependencies of GPL software must use a compatible license. Perens adds that the GPL Additional Permissions mechanism can be used to avoid some incompatibilities.

Is it a problem that the FSF introduced a new word?

There is some discontent that the GPLv3 introduces the term “intimate” which has no definition within the license or in legal usage. Such a vague word brings legal uncertainty, and might discourage (A)GPL use. Therefore, many people would like to see a clear statement from the FSF on the meaning of this word, in particular on when two programs perform intimate communication.

Bruce Perens explains why that is not going to happen: The GPL tries to discourage license circumvention attempts, so it will not use narrow language. As a matter of strategy, the FSF does not issue such clarifications because that would limit them. They want to be able to use the maximal interpretation available in a jurisdiction.

Scott Peterson points at the GPL FAQ for examples that discuss intimacy and at the GPLv3 rationale documents. The license draft had originally talked about “complex” data communication, but that was considered to suggest incorrect interpretations:

“Intimate” is the most useful term we know to describe the kind of convoluted interaction and deep knowledge that suggest that one part is specifically designed to require another part.

Lawrence Rosen is sceptical about the legal relevance of “convoluted interaction” and “deep knowledge” and thinks that the concept of Corresponding Source was “the worst mistake of GPLv3 drafting.” John Cowan thinks that “designed to require” is a useful test. Cowan points to the CLISP, which became available under the GPL because it required the readline library. But things get murky when considering alternative implementations: was a program using an alternative implementation designed to require the (interface of the) GPL-covered program? The FSF seems to think so, leading to proliferation of different APIs and compatibility wrappers.

Making sense of the law, and bright lines

When talking with engineers, Nicholas Weinstock has also hear some other ideas on what intimacy could mean here: Maybe two programs are intimate if their interaction was developed together? Or “intimate” could refer to categories of data rather than to the mechanism of communication?

Bruce Perens cautions that legal topics don't necessarily make sense for engineers. License compliance is required “whether or not it fits with conventional process in your industry.” Instead of trying to find ways to combine copyleft with proprietary code, the better approach is to architect the software to keep them clearly apart.

Rick Moen concurs: whether a work is derivative is for caselaw to decide, not for engineers or licenses. And there is little reason to think that courts would be impressed by coder's ideas regarding internal or external APIs, or different kinds of linking. This isn't just about the GPL but about using any kind of copyrighted material. The solution is to either hire legal help, pay for license exceptions, or to just stay away from areas of controversy.

John Cowan notes that the industry usage of a word might very well be relevant before a court, but unfortunately “intimate” has no industry usage.

Lawrence Rosen would like more clarity on technical architectures that safely allow use of copyleft interfaces. “No FOSS license that prohibits that is truly open source!” Bruce Perens seems a bit fed up with that attitude: some licenses clearly intend to prevent combination with proprietary software. “There is nothing about Open Source that says they have to give a free ride to anyone”. Suitable architectures clearly avoid derivative works and keep a “bright line” that would be “extremely clear to any court.”

Gil Yehuda thinks that if creating a compliant architecture requires a lawyer, that is a problem with the license. (Note: but this discussion is about architectures that avoid the need for license compliance!) No license can be simple, as Perens points out, because these legal documents rest on a huge body of case law. And even simple documents can have complicated results, for example an implied patent grant in the BSD license.

Great Expectations

Gil Yehuda thinks it is important to distinguish two separate motivations for using copyleft: some want Free Software, but others want to a license that is permissive enough to see their software be widely adapted, but still sufficiently restricted to convert some users to commercial licenses. There's nothing wrong with dual licensing (in fact, Bruce Perens considers dual licensing to be beneficial because it funds the production of more Open Source software) but it is unsurprising that there will be misunderstanding and frustration when dual-licensing businesses use Free Software licenses.

For example, Lawrence Rosen repeatedly suggests his OSL 3.0 as a less extreme network-copyleft license than the AGPL. Rosen reminds that Open Source is more than the GPL. Many other licenses are being proposed because the GPL doesn't fulfil those licensor's motivations. “Perhaps we should consider the intent of the SSPL licensors and help them create or use an alternative non-GPL license?” Bruce Perens notes that the SSPL goes far beyond the OSL as well. He writes: “Unfortunately, a lot of what these companies want to do can't be achieved as Open Source, and it is best that all sides understand that and go on.”

Relicensing and Maintainer–Community Dynamics

Out of the C-FSL discussion on the license-review list, a discussion forms about historical examples of maintainer–community dynamics, forks, and license changes. For context, the C-FSL gives some Original Authors the right to change the licensing of the code, without having to get extra permission from all copyright holders.

The typical mechanism for license changes is to contact all copyright holders. If a few copyright holders reject the change, their contributions can be removed. And this is workable, as history points out: Dungeon Crawl, Toybox, Mozilla, OpenSSL, OpenStreetMap are mentioned by Brendan Hickey and Rob Landley.

Rob Landley writes an epic email with lots of project histories. A fork is not necessarily an alternative version of some project, but could also be a new project that an existing community rallies around. For example, Linux could be interpreted as a fork of the Minix community.

Of particular interest is XFree86, which suffered a relicensing by its management. But: “The code survived, forked under new maintainership and a new name, with many of the same developers and inheriting pretty much all the users.” Looking forward, Landley asks: “The bad things happened anyway. What methods of organization survived the bad things?” Bruce Perens notes: “It is definitively a really good and important feature of Open Source licenses that developers can abscond from bad management.”

For the C-FSL, this means that it might be a very bad idea to give one group of maintainers too much power with the intention of preventing forks. For MongoDB's relicensing, it remains to be seen whether the community stays with the original project or moves to forks.

John Cowan cautions that forks can have many fates: while some might eat their parent and inherit the name (like GCC 3) or eat their parent under a different name (like LibreOffice) some also just fizzle out (like Drizzle from MySQL). But “Open-source software doesn't necessarily entail open-source development”. If the software is maintained cathedral-style rather than by a community, then giving the original developers special rights might not be a big deal. (Note: but what if the original maintainers cease to be good stewards? See XFree86 above.)

Developing a new Open Source License

Van Lindberg [1,2] announces that he is drafting a new open source license for Holo Ltd. and will submit it for OSI approval. The license will be AGPL-ish but have an option for an LGPL/Classpath style exception.

Bruce Perens notices that this license is planned to extend to all software “that implements a compatible API”. Such an extension of copyleft would violate OSD #9 “license must not restrict other software” and approval would seem undesirable for the OSI.

Van Lindberg understands and tries to be careful around this, especially since he has criticized similar problems with the SSPL. But if interfaces are copyrightable (cf Oracle v Google) then such a requirement would only affect derivative works, not unrelated software. VanL won't define interfaces but instead considers public performance rights. This is analogous to the AGPL network interaction clause, but better in line with copyright. (Note: I'd instead say that the AGPL just chooses to use one small aspect of public performance.)

Bruce Perens is sceptical of any extensions of copyleft/copyright, and points to Open Hardware as an example. The risk is that courts might consider this to be valid, thus extending copyright. But that would have a stifling effect, especially on Open Hardware. “Extension of copyright is bad for Open Source, even if it helps us enforce our licenses more effectively. It will always work against us to a greater extent [than] it can be put to work for us.”

Categories: FLOSS Research

2019 OSI Board Elections

Tue, 2019-01-15 12:16

The Open Source Initiative (OSI) is managed by a member-elected Board of Directors that is the ultimate authority responsible for the organization. The Board's responsibilities include oversight of the organization, including its operations, staff and budget; setting strategic direction and defining goals in line with the mission, and; serving the community through committees and working groups. The eleven person Board is composed of Directors elected by OSI Individual Members (5) and Affiliate Members (5). The General Manager of the OSI also serves on the Board as a Director (ex officio). The results of elections for both Individual and Affiliate Member Board seats are advisory with the OSI Board making the formal appointments to open seats based on the community's votes.

As a true corporate board, Board members must agree to, and comply with, the OSI Conflict of Interest Policy, and all Directors are expected to participate regularly in monthly Board meetings, any special meetings that may arise and the ongoing discussions related to the OSI specifically and open source generally.

Open Seats

(More information below, see "Nominations")

Upcoming 2019 Election Schedule
  • January 14, 2019: Announcement of election.
  • February 3, 2019 (12:00 a.m. PST): Nominations open
  • March 1, 2019 (11:59 p.m. PST): Nominations close
  • March 4, 2019 (12:00 a.m. PST): Elections open
  • March 15, 2019 (11:59 p.m. PST): Elections close
  • March 18, 2019 (12:00 a.m. PST): : Run-off elections open (if needed)
  • March 18, 2019 (11:59 p.m. PST): Run-off elections close
  • April 1, 2019: New Board Directors seated
  • May 6 & 7, 2019 : First in-person Board meeting (New York, NY)
Terms of Offices

No Board Director who has served for six consecutive years is eligible for re-election until a year has elapsed. As an example, someone elected to an Individual Member seat three consecutive times, and thus serving 6 consecutive years, or someone elected to an Affiliate Member Seat twice consecutively, and thus serving 6 consecutive years, will be term-limited and unable to be elected for a further consecutive term for either an Individual or Affiliate seat until a year has passed.

The representation of the board is as follows:

  • 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 Director of the Board will be dedicated to the General Manager, ex officio (term to last length of employment)
Election Process

Nominations
Only current OSI Individual Members may run for an Individual Member seat on the Board (learn more about joining the OSI as an Individual Member), however those running for an Affiliate seat on the Board need not be an Individual Member. Those interested in running for an Individual Member seat do not need to be nominated and may run by simply completing the candidate information. Those interested in running for an Affiliate Member Board seat must be nominated by a current OSI Affiliate organization.

Standing for election is extremely easy. Current Individual Members who would like to run for an Individual Member seat can simply send a contact request, with the category “Candidate Nomination” via the OSI contact form (http//opensource.org/contact).

Current Affiliate Members may send their nominations for Affiliate Member seats to the OSI via the OSI contact form (http://opensource.org/contact). Please select the “Candidate Nomination” category on the form.

Once we receive your request, we will promptly send you back information to create your election profile. Current election eligibility policy can be found here in the OSI Bylaws, Article V, Sections 3 - 5.

Voting
Voting in OSI elections is open to all Individual Members and the OSI Representatives of each 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. Only one vote per Affiliate Member, as submitted by the Affiliate Representative will be counted in the election of an Affiliate seat. Elections for OSI Directors are held according to Bloc voting, or plurality-at-large, where each eligible voter votes for as many candidates as they feel are qualified to hold a Board seat. The candidates supported by the greatest number of voters will be elected to the open seats. Should a tie occur, a run off will be held between the tied candidates.*

Voting for all elections is done online using Helios Voting. When elections are held, OSI current and lifelong Individual Members and the Affiliate Members' Representatives receive email notifications with instructions on how to access the online voting systems, instructions on how to complete their vote, and a list of the candidates with further information about them and their interests/qualifications.

Becoming a member
If you are not an Individual Member and would like to vote in the election for an Individual Member seat, and/or run, for an OSI Individual Member Board Director seat, please consider registering for Individual Membership. Your participation is fundamental to make the OSI more community oriented and to better represent your interests. You can vote in the next election becoming a member now through the end of the election calendar. You may stand for election as long as you join, before nominations close.

OSI Election FAQ

Can I run for an Individual or Affiliate Member seat?
Yes, you can run for either seat, but not both during the same election.

In addition, to run for an Individual Member seat, you must be a current OSI Individual Member . However, you do not need to be an Individual Member to run for an Affiliate seat on the Board. Also, as the Affiliate Member seats are nominated by OSI Affiliate Member Representatives, each Affiliate may have their own requirements to earn their nomination (e.g. membership in their organization).

What do I need to do to be a candidate for an Individual Member, or Affiliate Board of Director seat?
To be a candidate for an Individual Member seat, you must be a current OSI Individual Member .

To be a candidate for an Affiliate seat on the Board you must be nominated by an OSI Affiliate Member Representative. Each Affiliate Member may have their own requirements to earn their nomination (e.g. membership in their organization).

What if I'm not an OSI Member and want to run?
Individual Membership is easy, and you can become a member right now, and still run for election. You may also contact an OSI Affiliate to ask about a nomination from them.

Can I nominate someone else for an Individual Member Board seat?
No. The OSI Board needs to have the commitment of the candidate that they are really willing to serve on the Board. But, you can contact your desired candidate and suggest that they self-nominate. All that is required is that they send an email!

  • Won't that leave out important candidates from this election?
    If candidates don't have time or are not interested in completing a simple form to self-nominate themselves, they probably don't have time, nor interest, to serve on the OSI Board, so they would not really be qualified candidates anyway.

Can I nominate someone else for an Affiliate Member Board seat?
No. Only OSI Affiliate Member organizations may nominate candidates for Affiliate Board seats.

Can I run for both an Individual Member Board seat and an Affiliate Member Board seat?
No. Candidates may only stand for one seat during each election.

As an Individual Member, can I vote for Individual and Affiliate Member candidates?
No, as an Individual Member you may vote only for candidates running for Individual Member seats on the Board. Affiliate Member representatives vote for candidates running for Affiliate seats on the Board. If you are both an Individual Member and an Affiliate Member representative you may vote for both Individual and Affiliate Member seats.

Categories: FLOSS Research

December 2018 License-Discuss List Summary

Mon, 2019-01-07 10:51

I've been asked to provide monthly summaries of the license-review and license-discuss mailing lists. The summaries will also be posted on their respective lists, though this blog version includes detailed links into the list archives. Any feedback is welcome, though replies on the content should of course be made to the original threads.

This month's topics:

  • International Licenses Redux
  • Proposed license decision process
  • "Consideration" in open source licenses
  • Open source license with obligation to display an attribution?
  • SSPL loose ends

License-Review summary: https://opensource.org/LicenseReview122018

International Licenses Redux

Richard Fontana suggests that the “International” license category should be expanded from non-English language licenses (LiLiQ) to cover licenses "targeting specific languages and jurisdictions", regardless of their language (EUPL, CeCILL). Language and jurisdiction are intertwined, as Mike Milinkovich explains: “By convention, OSS expects English as the language of the license, but there are places in the world where that is legally impossible [due to statutory language requirements].”

Proposed license decision process

Richard Fontana posts a draft for a clarified license decision process as discussed by the OSI Board. The proposal adds a clear Decision Date 60 days after initial license submission after which the OSI will defer the decision if discussion is ongoing, approve or reject the license if the discussion is conclusive, or withhold approval if the license can be reworked.

Bruce Perens appreciates that “software freedom” is an explicit goal of the proposed decision process, but notes that the term can be unclear. Lawrence Rosen argues that open source should be based on a more pragmatic definition.

Luis Villa asks about a specific test for software freedom, and whether license review would be coordinated with the FSF. Richard Fontana replies that he considers the OSD to be an attempt of a definition of software freedom, but that the OSD is limited and should not be viewed as as checklist or interpreted too literally. Focusing on software freedom as the actual goal would help avoid this. While Fontana would like to see greater harmonization between OSI and FSF wrt decisions on edge-case FOSS licenses, he doesn’t think their very different review processes should be closely coordinated.

What about harmful licenses that have been accepted by the OSI in the past? Perens specifically considers the SIL Open Font License. Rick Moen thinks that these licenses are a lingering though minor problem since there's a community expectation to use one of the major licenses. Luis Villa thinks a cleanup of old licenses might be a good idea and could also provide “case law” for the new license review process. Nicholas Weinstock would prefer existing licenses to be grandfathered.

“Consideration” in open source licenses

As a more pragmatic basis for the license review process than "software freedom", Lawrence Rosen proposes:

“Open source software” means software actually distributed under terms that grant a copyright and patent license from all contributors to the software for every licensee to access and use the complete source code, make copies of the software or derivative works thereof and, without payment of royalties or other consideration, to distribute the unmodified or modified software.

A discussion starts on the “without consideration” point. Florian Weimer notes that this term is difficult to understand outside of common law. For example, Kevin P. Fleming and Nicholas Weinstock note that the copyleft requirement to distribute source code might be interpreted as a consideration. Bruce Perens responds that the Jacobsen v. Katzer case shows that open source licenses do indeed have non-monetary considerations.

Lawrence Rosen insists that “considerations” should not be confused with “conditions”. Rosen claims that no open source licenses require considerations but that the OSI accepts some license conditions (e.g. copyleft conditions). Rosen thinks that creating open source software or receiving attribution is its own reward. (Note: Rosen’s distinction between considerations and conditions seems to prove Weimer’s point, and the claim about considerations directly contradicts Perens.)

A number of OSI-approved licenses explicitly mention considerations and conditions, as noted by Nicholas Weinstock. Perhaps the concepts can be distinguished by whether rights are surrendered or gained? Rosen agrees that these terms can have “subtle legal meanings, including in other countries” but explains that a consideration can be anything valued by the licensor, including "Peppercorns".

Nigel Tzeng notes that it is exactly the acceptable level of considerations that is at question for an open source license: “Some forms of consideration is okay, even good. Others become overreach.” Rosen acknowledges that and explains that he is primarily concerned about considerations by downstream users. (Note: it seems Rosen’s gripe with considerations is not so much the consideration itself, but that there might not be a clear recipient of the consideration.)

Regarding the “actually distributed” part, Nicholas Weinstock notes that the BSD license might fail that criterion since it has no express patent grant. Lawrence Rosen agrees and would object to new licenses without an explicit patent grant. In fact, licenses that expressly exclude patent grants have been rejected. However, Rosen acknowledges that especially academic licensors might only be able to provide limited grants. Rosen also points to possible issues around open standards.

Open source license with obligation to display an attribution?

Simon Cox asks [1,2,3] whether any open source license requires public attribution as a gesture of acknowledgement, e.g. as a logo on a website. Such attributions would make it easier to demonstrate the impact of open source projects, especially in the public sector/GOSS as emphasized by Stephen Michael Kellat.

Such attributions can be tricky. Danese Cooper recalls the tension between the OSI-approved Attribution Assurance License AAL and SugarCRM’s previous requirement to display their logo in the middle of each page (cf ZDNet) which was considered counter to the OSD. David Woolley mentions the difficulty around the advertising clause in the 4-clause BSD license.

Antoine Thomas notes [1,2] that attribution is usually not a problem since all attributions in a software are typically gathered on a separate page. Thorsten Glaser responds that this is only possible if the license is technology-neutral and doesn’t prescribe a specific attribution style. Glaser also raises the issue that a requirement for public attribution could fail the “Dissident” or “Desert Island” test (see DFSG).

Bruce Perens mentions two issues with “badgeware”: It would trigger requirements on mere use, and would make compliance infeasible for large projects such as Debian. Lawrence Rosen points out that OSD #10 “License Must Be Technology Neutral” prevents some badgeware licenses.

Bruce Perens notes that attribution requests rather than requirements are unproblematic. Lawrence Rosen thinks that mild requirements are perfectly reasonable, e.g.: “Licensee must display the name and source of the embedded software in as prominent a manner and place as the licensee displays its own trademarks.”

Rosen also voices an interesting view on the license review process: “Our job is to approve licenses that experiment successfully (?) with new license models, not to keep rejecting ways to obtain profit and recognition from software. Let us leave it up to the marketplace to determine acceptability of the license, as long as it is ‘open source software.’”

Chris Lamb suggests [1,2] adding a rider with an attribution request to any well-known license, e.g. the GPLv3. (Note: this could be a GPLv3 Additional Term.) Lawrence Rosen claims that the GPLv3 “doesn't protect attribution in derivative works.”

Regarding the Government Open Source Software (GOSS) attribution aspect, Nigel Tzeng expresses considerable frustration with respect to available open source licenses and the open source community. Visible attribution is often needed by public projects to ensure future funding.

Jim Jagielski and Lawrence Rosen disagree that GOSS would be fundamentally different from other projects in this respect. However, Rosen agrees that present licenses such as the GPLv3 fail to ensure sufficient attribution.

Christopher Sean Morrison lists a few US-specific problems or unresolved legalities that GOSS faces. This limits public sector participation in open source: “Nobody wants to be the guinea pig.” Tzeng points to the NASA and ECL licenses as examples where other public sector needs already made specific licenses necessary.

SSPL loose ends

The submission of the SSPL sparked lots of discussions about copyleft and review processes in general. A number of loose ends:

Kyle Mitchell followed up on two points from November. Responding to the older Freedom or Power? essay, Mitchell notes that there isn’t just the essay's producer–user power imbalance, but also an imbalance between producers. Mitchell argues that non-permissive licenses such as the SSPL are necessary to protect producers from their competitors.

There have not been many supporters for the SSPL. Mitchell notes that the number of supporters should not matter, so that the license review process doesn't turn into a popularity contest.

Previously, Kyle Mitchell had noted that some OSI-approved licenses trigger requirements on use and not just on copying: the OSL and AGPL. Florian Weimer thinks that the AGPL was originally intended for servers that also serve their source code and not for open-core business models. “People who have tried to use the AGPL in this way have been disappointed about the effects, I believe.” Weimer wonders whether such business models were a consideration for the OSL.

Should a license review focus on the license text or its potential use? Florian Weimer prefers a textual review because this avoids having to take a stance on Open Core business models. Brendan Hickey clarifies that a 2010 post on the OSI blog about this is a personal opinion and not official OSI stance.

Categories: FLOSS Research

December 2018 License-Review List Summary

Mon, 2019-01-07 10:49

I've been asked to provide monthly summaries of the license-review and license-discuss mailing lists. The summaries will also be posted on their respective lists, though this blog version includes detailed links into the list archives. Any feedback is welcome, though replies on the content should of course be made to the original threads.

This month's topics:

  • License committee report and review status changes
  • Server Side Public License, Version 2 (SSPL v2)
  • Support for SSPL v2
  • (A new license review process is being discussed on the license-discuss list)

License-Discuss summary: https://opensource.org/LicenseDiscuss122018

License committee report and review status changes

Report by Richard Fontana

libpng license: Cosmin Truta withdraws the license.

SSPLv2: discussion will continue on the revised version.

YetiForce Public License 3.0: rejected.

License Zero Public License (L0-R): no decision because it had been effectively withdrawn.

Convertible Free Software License, Version 1.1: approval withheld pending a redrafted version. Elmar Stellnberger (the license submitter) is not certain which points would have to be changed. Carlo Piana emphasizes that giving the original authors special relicensing rights is discriminatory, especially in case of a fork.

Server Side Public License, Version 2 (SSPL v2)

On Nov 21, the SSPL v2 has been submitted for review.

Eric Schultz feels the revision has not been made in good faith and finds no substantial improvements. Schultz is particularly concerned that the “limitations what code is included on Section 13 seem practically limitless because Service is not defined.”

Bruce Perens links to Sunil Deshpande’s comments on the SSPL and feels “it manifests a lot of ignorance about Open Source and utter contempt for our community.” Eliot Horowitz (MongoDB) responds that Deshpande is unaffiliated with MongoDB. Instead, Horowitz points to an article on his blog. He also responds to individual issues:

Is it a problem that the SSPL extends to other software? Horowitz argues “no”: combining services over a network is the new dynamic linking, so it's OK to extend copyleft. (Note: this fails to consider the bounds of copyright, and that the SSPL would not just affect other services but e.g. deployment tools.) McCoy Smith is also concerned that the SSPL could require the disclosure of software that is similar or reverse engineered, without being a derivative work in the sense of copyright.

What constitutes making the Program available as a service? Horowitz claims that the SSPL's definition is easier to understand than the comparable section in the AGPL, and says the license cannot be more specific while remaining technology-agnostic and understandable.

Florian Weimer asks whether this would include services like providing pre-built binaries. Horowitz (MongoDB) responds that the terms covering distribution of binaries are identical with the GPL. Horowitz explains that running the software as a service here means running the software on behalf of someone else, and that this meaning is common and well understood.

(Note: I previously read the SSPL with service as in service oriented architecture, not as in cleaning service. Apparently, only service as in SaaS/PaaS is meant. Common usage or not, this is quite ambiguous.)

Lawrence Rosen takes issue with the SSPL’s “making available” definition: the “value” of a service cannot be calculated, and what a program “accomplishes for users” is subjective and addled by marketing. “You have created, at least in part, an unenforceable FOSS license with a nicer definition than AGPL of "program as a service" that still doesn't help much. :-)”

Nevertheless, Rosen thinks the flaws of the SSPL do not prevent it from being an open source license and votes for approval as an experimental license.

Support for SSPL v2

Greg Luck (Hazelcast) voices support for the SSPL v2. He argues that there is a need for an OSI-approved license addressing the issues raised by the Commons Clause and SSPL in order to prevent proliferation of open source-ish licenses in this area. Luck considers GPLv3 style copyleft and even the AGPL insufficient at preventing service wrapping by cloud providers. In his understanding, copyleft should prevent selling free software or the original developers should get a fair share of the profits.

Rob Landley responds that Stallman was well aware of the “service provider loophole” prior to creating the (A)GPLv3 license family. “If he and Eben Moglen working together for half a decade couldn't manage to address the issue and still call the result "Free Software", what makes you think you're going to?” Landley accuses SSPL supporters of wishful thinking: “that's now how copyright law and open source work”.

Carlo Piana sympathizes with Luck’s sentiment but doesn’t think the SSPL should be the license that OSI approves for this purpose. Piana is particularly concerned that the SSPL is so unclear in so many scenarios that most users are effectively forced to obtain a proprietary license. “It's the dual licensing paradigm on steroids”. Nigel T concurs and suggests that it’s not the responsibility of open source to enable a particular business model: “If you don’t want folks to profit from your codebase just make it shared source and move on.”

Bruce Perens adds that the “OSI doesn't prevent you from using any license. Just don't call it Open Source.” Perens points out that the OSD/DFSG ban on usage restrictions excludes some special interests, e.g. educational-only software. This is necessary so that an open source system can be used with legal certainty, for any purpose. But where are the communities that promote special non-open source licenses? “IMO the problem for some of the proposed licenses is not a lack of OSI's approval, but a lack of interest.” Nigel T points at CC-NC as a non-open license with a large community.

Perens also responds that any confusion due to a proliferation of non-OSS licenses “will not be OSI or Open Source's problem. You create this problem by leaving the tent.”

Brendan Hickey points out Luck’s misunderstanding of Free Software: it’s about reciprocity, not about encumbering commercial interests. Furthermore, Hickey argues that cloud providers sell reliability, not software. Therefore, the SSPL will not prevent large cloud providers from profiting from hosting open source software but at most inconvenience users.

Martin Verburg (jClarity) [1,2] chimes in with support for a common license that addresses these concerns, but advises caution – acceptance of such a license or even changing the OSD would have far-reaching and long-lasting effects. Instead he suggests a Infrastructure License Consortium in which vendors should develop a common license, independent of possible OSI approval. Regarding the SSPL, Verburg suggests to wait and watch: will other vendors take up this license?

Categories: FLOSS Research