-
Affirmation of the Open Source Definition
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
-
January 2019 License-Review Summary
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.
-
January 2019 License-Discuss Summary
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.”
-
2019 OSI Board Elections

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.
-
December 2018 License-Discuss List Summary
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.
|