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

[Add your organization's name to our growing community protecting open source software, development and communities: contact us now.)

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 Hong Kong
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

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.

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

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

• Two Affiliate Member seats - candidates must be nominated by an OSI Affiliate Member.
• Four Individual Member seats - candidates must be an OSI Individual Member.

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

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.