Skyrack News and Announcements
Other Industry News
Open Source Initiative
- Fri, 13 May 2016 13:56:14 +0000: Visit us at OSCON in Austin – Open Source Initiative blogs
Here is a roundup of what to watch out for from the OSI in Austin, Texas.
Community Leadership Summit
For those of you attending Community Leadership Summit, there will be several people from the OSI who are always eager to talk open source and otherwise. Don’t hesitate to approach us and say hello!
OSCON Expo Hall
We will have a booth (#231-1) in the OSCON expo hall where we will have stickers, patches, our highly popular OSI neck pillows, and perhaps more! Come along to say hello, and be sure to bring your friends. We will be recruiting new members, and will be very interested in your ideas to help run the OSI and promote open source software.
OSI Office Hours
Throughout OSCON we’ll be hosting office hours where you can discuss your interests and issues with not only OSI directors, but also some of our Affiliate Members. Interested in starting a project, talk it over with Stefano Zacchiroli; want to build a developer relations team, get some advice from Leslie Hawthorn; talk to Mike Milinkovich about how to get your project under a foundation.
There is a lot of representation from current and former board members in OSCON talks and panels this year.
Our current board member Deborah Bryant (Twitter) will be on a panel with former board member Danese Cooper (Twitter) about Open Source Foundations. This promises to be a very useful session to teach you how to set up the foundations of an open source entity.
Leslie Hawthorn (Twitter), a current board member, will be co-presenting “I am your User, Why Do You Hate Me?“, a talk that brings a private rant public, where she and her co-presenter, Donna Benjamin, will address Open Source projects that can be somewhat prickly towards their users.
Other former board members who we will hear from are Chris DiBona (Twitter), on a panel teaching us Open Source Lessons from the TODO Group; Matt Asay (Twitter) will reveal the truth about open source businesses; and Jim Jagielski (Twitter) will be part of a panel speaking about Aligning Patents and Open Source.
If you don’t have your ticket yet, don’t forget that as an OSI member, you get a 30% discount off of regular ticket prices, or a free pass for the expo hall!
- 30% Discount Code – PCOSI
- Free Expo Hall Pass – PCEXPO
Share Your Expertise!
In addition to our booth, we will be doing video interviews with members who would like to share information about their projects. We would love to hear what you have to say! Recording times can be found here. Sign into your account (or register yourself on the wiki) to edit the page and sign yourself up for a time slot.
Our booth is already fully staffed, but if any members would like to sign up to have office hours in which to share their expertise, you can do that right here!
For those of you who cannot make it this time – be sure to keep an eye on our Twitter account for updates throughout the week of OSCON so you don’t miss a thing!
- Sun, 01 May 2016 01:28:50 +0000: Open Source Elections System: Update from City & County of San Francisco, California USA – Open Source Initiative blogs
The OSI has has voiced our support to recent efforts by the City and County of San Francisco’s Department of Elections to develop an open source voting system. The following is an update provided to the OSI from Commissioner and Vice President of the Elections Commission, Chris Jerdonek.
A lot has happened this past month in the movement for San Francisco to develop and certify the country’s first open source voting system!
As a reminder, this would be a paper-ballot system running on commercial-off-the-shelf hardware, so it would be 100% transparent to the public, as well as more affordable and more flexible to the City.
This e-mail contains an extended update to bring you up to speed on much of what has happened since last month. It is organized into the following sections:
1. City budget progress
2. New supporters!
3. More presentations & media coverage
4. Related news
On to the first update section…
1. CITY BUDGET PROGRESS
The SF open source voting system project continues to work its way through the City’s budget process.
The Mayor will submit his citywide draft budget to the Board of Supervisors on or before June 1. Thus, the Mayor will continue to decide over the next month whether and how much money to allocate to the project for the City’s next two fiscal years (starting July 1, 2016 when the City’s fiscal year begins).
If you recall, in February the SF Department of Elections requested $2.3 million for the first year of the project, and more for the second year. The Mayor has since referred the project to the City’s Committee on Information Technology (COIT) for review. COIT is a 16-member body made up of city department heads and charged with setting the overall technology direction of the city government.
The Department of Elections presented the open source voting system project to COIT’s Budget and Performance Sub-Committee at its public meeting on Friday, April 1. The open source voting project is one of about 60 city technology projects that the sub-committee reviewed and discussed this year. On Friday, April 15, the sub-committee voted to recommend that $300K out of COIT’s $10.5 million allocation go to the project (as part of a larger vote making recommendations on all 60 projects). The $300K is enough to fully fund the “planning phase” (Phase 1) of the project.
This is good news in that it shows support for the project in concept from the sub-committee by them “green-lighting” it. However, it’s not enough to fund anything beyond planning in the first year. For example, in the absence of additional funds, the earliest the Department of Elections would be able to issue its first RFP for actual development work would be July 2017. It’s important for the City to use each month that passes effectively, since it’s not clear how long the Department will be able to continue using its current, aging voting system.
Remember that the alternative to the City developing and certifying an open source system is to procure a proprietary voting system like it did before. In 2007, this carried the hefty price tag of $13.8 million for the first four years ($15.8 million in today’s dollars). And that rose to $19.7 million (unadjusted) when including through the end of 2016. But going the open source route requires giving the Department enough support and lead time for development and certification.
The full COIT body will be taking into account the COIT sub-committee’s recommendation and making its own funding recommendation, most likely at its meeting on Friday, May 6, 2016 at 10am in Room 305 of SF City Hall. The Mayor will use COIT’s recommendation in informing his own decision as to how much money to allocate for the project.
There is still time to contact the Mayor and recommend that the Department’s full budget request be granted. The Mayor will submit his draft budget to the Board of Supervisors by June 1
2. NEW SUPPORTERS!
More significant names have added their voices to the list of supporters asking Mayor Lee and the Board of Supervisors to fully fund the project to be ready in time for the June 2020 election.
At its April 13, 2016 meeting, the San Francisco Democratic County Central Committee (DCCC) passed a powerful resolution “urging the Mayor and Board of Supervisors to champion and fully fund … the development and certification of an open source voting system.” See the bottom of this e-mail for the full text of the resolution. The DCCC resolution is significant because the DCCC is a large body made up of 32 member-leaders, including several local, state, and national elected officials. The resolution passed without any opposition. Kudos to the SF DCCC for recognizing the importance of this issue!
The following San Francisco organizations and individuals also added their voices in the last month:
San Francisco Technology Democrats (SF Tech Dems)
Harvey Milk LGBT Democratic Club
Brian Behlendorf, Co-Founder of the Apache Software Foundation
Nadia Eghbal, open-source writer, researcher, and speaker
and many others.
(The latest list can be found in one of the handouts here:
To add your own name to the list or to suggest a different organization to approach, feel free to e-mail me back.
Additional fun fact: In the process of watching the DCCC resolution process unfold, I learned that the California Democratic Party’s 2016 Platform itself supports open-source voting. See the bottom of this e-mail for details and the actual language around open source voting in their platform.
3. MORE PRESENTATIONS & MEDIA COVERAGE
On March 24, the day I last sent an e-mail update, the Board of Supervisors Rules Committee held a hearing on the open source voting system project. The hearing focused on the timeline and budget for the project.
For a video of the hearing, you can visit the following link (the agenda item starts 3:02:06 into the meeting, or else click the last hyperlinked agenda item to the right): http://sanfrancisco.granicus.com/MediaPlayer.php?view_id=13&clip_id=25013
The agenda packet for the hearing can be found here (including slides for a presentation I gave at the beginning of the hearing):
One exciting development on this: one of NBC News’s investigative teams attended and filmed the Rules Committee hearing for an upcoming series they’re doing on voting machines. The series will air sometime this summer, with one of the segments focusing on San Francisco’s open source voting project. This is great news (literally)!
Also, last Friday I gave a brief presentation at a San Francisco tech event called Open Source Show & Tell:
The audience was very interested and supportive of the project.
If you know any groups that might like a brief presentation on the project, feel free to get in touch with me.
4. RELATED NEWS
In related news, a month and a half ago, the White House issued an exciting federal draft source code policy on software custom-developed for the government.
The draft policy heavily featured open source. Public comment on the policy closed a week ago last Monday, April 18. Many state and federal agencies commented publicly in support of the use of open source software, including 18F (an innovative branch of the federal GSA, with an office at our own UN Plaza near City Hall), the California Health and Human Services Agency, the California Department of Technology, and the Department of Homeland Security.
[The OSI also provided comments.]
The California Health and Human Services Agency and California Department of Technology, for example, wrote publicly, “California endorses the Federal government’s position on the use of open source software and feels strongly that it is an excellent investment as a public good….”
Finally, two Sundays ago the New York Times wrote an excellent editorial on the sorry state of voting machines in our country (“Why Americans Can’t Vote,” 4/16/2016). I encourage you to take a look:
The editorial is further background to the critical importance of the SF open source voting project, not just to elections in San Francisco but across the country. It’s another sign that SF is focusing on something important.
Thanks for reading this e-mail, and thank you for your continued support!
Resolution passed by the San Francisco Democratic County Central Committee (DCCC) at its April 13, 2016 meeting:
RESOLUTION IN SUPPORT OF AN OPEN SOURCE VOTING SYSTEM FOR SAN FRANCISCO
WHEREAS, elections are a public process at the core of our democracy and so demand the highest levels of transparency, accessibility, security, and integrity; and
WHEREAS, proprietary voting software and hardware are hidden from public view, lead to private vendor lock-in, and result in perpetual software licensing fees and service contracts that are expensive to taxpayers without investing in a lasting public good; and
WHEREAS, the Board of Supervisors unanimously passed a resolution authored by Supervisor Scott Wiener supporting the creation of an open source voting system running on commodity hardware, a system whose software would be free for anyone to view, use, and improve, and so be 100% transparent to the public, more affordable, more adaptable, and would benefit not just San Francisco but election jurisdictions across the United States.
NOW THEREFORE BE IT RESOLVED that the San Francisco Democratic County Central Committee (DCCC) finds the objectives of an open source voting system to be central to the Democratic Party’s core values of active and transparent voter participation and therefore supports the creation and use of a paper- ballot open source voting system that can run on inexpensive, commercially available hardware; and
BE IT FURTHER RESOLVED that the DCCC join the San Francisco Elections Commission, California Common Cause, the Electronic Frontier Foundation (EFF), Code for San Francisco, and many other individuals and organizations in urging the Mayor and Board of Supervisors to champion and fully fund, starting with the upcoming 2016-2017 fiscal year, the development and certification of an open source voting system for San Francisco to use starting with the June 2020 election.
(Introduced by DCCC member Joshua Arce and co-sponsored by Rebecca Prozan)
Excerpt of the parts of the California Democratic Party 2016 Platform mentioning open source voting:
California Democratic Party 2016 Platform
We demand open and fraud-free elections and incontrovertible government accountability to the electorate. … We support public ownership of all election processes, software and equipment. … To promote honest leadership and open government, California Democrats will … Demand transparency at every stage with voting system software (including open-source software);
- Mon, 18 Apr 2016 18:14:33 +0000: OSI’s Comments to the White House Office of Management and Budget Regarding the “Federal Source Code Policy” – Open Source Initiative blogs
Note: The following comments were submitted to the White House Office of Management and Budget, regarding the “Federal Source Code Policy” on behalf of the OSI https://github.com/WhiteHouse/source-code-policy/issues/227
The Open Source Initiative (OSI) <https://opensource.org> was chartered in the late 1990s as a California 501C3 to advance open source licensing and development in order to raise awareness and adoption of open source software. Today, the OSI continues to promote open source principles and practices, and protect the open source label through, education, public advocacy and community building. As the steward of the Open Source Definition (OSD) <https://opensource.org>, through approval of licenses as “OSI-certified”, and by establishing such approval as the standard for open source software development and distribution, the OSI has become a cornerstone of software freedom.
The OSI is internationally acknowledged as the sole authority for certifying open source licenses as compliant with the OSD. The OSD is the gold standard of open source licensing, and the OSI, as a standards body, is trusted by the developer community as well as businesses and governments around the world. Organizations from across the globe have submitted licenses to the OSI for review and approval, these include: Apple, Computer Associates, IBM, Microsoft, Nokia, Oracle, The University of Illinois National Center for Supercomputing Applications, The University of Indiana, NASA, The European Commission, The Provincial Government of Quebec, as well as the Eclipse, Mozilla, PHP, PostgreSQL, Python, the World Wide Web Consortium (W3C) and many, many more.
OSI Board Members frequently travel the world to attend open source conferences and events, meet with open source developers and users, and discuss with executives from the public and private sectors about how open source technologies, licenses, and models of development can provide economic and strategic advantages. Most recently, within the government sector, the OSI has worked with New York City, the City and County of San Francisco, the provincial Government of Quebec, Canada, the State of California, the State of New York, the Government of India, and the The White House to provide input on factual matters related to open source software licensing and development as an enabler of software freedom.
In addition, the OSI is privileged with a growing membership including some of the worlds most successful open source projects—unequivocally independent groups with a clear commitment to open source—who strengthen our mission to educate about and advocate for the benefits of open source and to build bridges among different constituencies in the open source community. The OSI’s current membership includes, among many others, Creative Commons, Debian, the Drupal Association, Eclipse Foundation, FreeBSD Foundation, Linux Foundation, Mozilla Foundation, Open Source Electronic Health Record Alliance (OSEHRA), Python Software Foundation, Wikimedia Foundation, Wordpress Foundation. Each Affiliate Member commits to upholding the mission, values and objectives of the Open Source Initiative and the Open Source Definition.
General Comments & Alignment with the Policy: Explicitly require OSI Approved Open Source Licenses.
The OSI is very pleased with the recent commitment to adopt a Government-wide Open Source Software policy within The White House Office of Management and Budget (OMB) as outlined in the “Federal Source Code Policy – Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software” <https://opensource.org>. We agree that such a policy “will support improved access to custom software code developed for the Federal Government,” and “can fuel innovation, lower costs, and benefit the public.” <https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/README.md>.
Governments around the globe recognize the value of open source as both a technology solution delivering value to the public they serve, as well as an approach for development returning tax-payer investments back to the society they represent. The implementation of the Federal Source Code Policy will be a key component in “reducing Federal vendor lock-in, decreasing duplicative costs for the same code, increasing transparency across the Federal Government, and minimizing the challenges associated with integrating large blocks of code from multiple sources” (Line 30, Federal Source Code Policy).
Most significantly, for the OSI and the open source software community, is the recognition of the Open Source Initiative itself and our role, OSI Approved Licenses, and the authority of the Open Source Definition, specifically:
- “a valid open source license is one that is approved by the Open Source Initiative https://opensource.org/licenses”;
- “Open Source Software (OSS): Software that can be freely accessed, used, changed, and shared (in modified or unmodified form) by anyone. OSS is often distributed under licenses that comply with the definition of “Open Source” provided by the Open Source Initiative https://opensource.org/osd”, and;
- “the most widely-recognized definition of “Open Source Software” – both in the U.S. and internationally – is provided by the Open Source Initiative, and provides 10 criteria that software must meet to be considered open source. This definition is accessible at https://opensource.org/osd.”
Because the OSD is an internationally recognized standard, OSI approved licenses ensure software freedom, and provide permission first to implementing organizations so that they can adopt, adapt, improve and innovate. As former OSI President Simon Phipps wrote, “Increasingly in today’s society we expect that an individual can take action to use or improve [open source] software and a widening range of other artifacts without needing to ask permission first.” As he notes, this requires that “permission is given in advance and can be assumed. That’s the governing principle of open source. OSI approved licenses guarantee we have the freedom to use, study, improve, and share software source code, so everyone has permission in advance to solve their own problems using that software without seeking permission first” <http://www.infoworld.com/article/2608195/open-source-software/governance-for-the-github-generation.html>.
An OSI approved license assures organizations—like those within the U.S. Federal Government—that the software they are interested in implementing, is indeed “open source software.” The OSI’s License Review Process, “ensures that licenses and software labeled as ‘open source’ conforms to existing community norms and expectations” <https://opensource.org/approval>. All licenses must go through a review process which includes, alignment to the Open Source Definition, identification of appropriate License Proliferation Category, assessment of “vanity” and duplicative licenses, and public review and comment. The OSI Board consults with submitting entities in advance to help them navigate the process and improve their license, but formal approval requires going through license-review .
It is only because of the recognition of the OSD, as a standard and the OSI’s License Review process, that organizations have been so successful in collaborating around, contributing to, and co-creating the spectacular collection of open source software available today. Without such a standard, process, and oversight organization, ambiguity and uncertainty will arise. Unfortunately, as organizations who actively and authentically participate in the development of software distributed with an OSI approved license reap the business, economic, operational, and technical benefits, as well as garner public accolades and increased profile from that success, “openwashing” <http://michellethorne.cc/2009/03/openwashing/> and “fauxpen source” <http://www.fauxpensource.org/> become more prevalent. Michelle Thorn, Mozilla’s Director of the Webmaker Program, was the first to define openwashing in 2009, “to spin a product or company as open, although it is not,” while fauxpen source was introduced by Phil Marsosudiro, as “a description of software that claims to be open source, but lacks the full freedoms required by the Open Source Definition.”
This is not a theoretical problem, as several recent examples illustrate, for example:
- Qabel labels itself as “open source” but is not. According to their website, Qabel is a free, open-source and expandable platform. Yet their license includes restrictions that would impose serious limits on its use by a government, “No license is granted by the Original Copyright Holder for military, intelligence or related purposes, including but not limited to intelligence and military research” <https://qabel.de/en/license>.
- SailfishOS promotes open source, but is not licensed as such: “Your tablet is powered by open source software called Sailfish” (https://www.youtube.com/watch?v=jBQdfcLhts8 minute 1:05). However Jolla states in the SailfishOS End User License Agreement, “Although we encourage you to develop our Software to make it better, we cannot allow such development, modifying or any harmful interaction with the version of our Software distributed integrated in a product” <https://jolla.com/sailfish-eula/>. This approach will cause confusion and barriers for governments who have already identified SailfishOS as their preferred mobile operating system <http://www.jollausers.com/2015/05/sailfish-os-to-become-russias-official-operating-system-for-mobile/>.
- The Fair Source License seeks to align itself with the open ethos, but actually hinders wide adoption: “The Fair Source License allows everyone to see the source code and makes the software free to use for a limited number of users in your organization. It offers some of the benefits of open source while preserving the ability to charge for the software” <https://fair.io/>. However, as former OSI Director and current Vice President of Mobile at Adobe, Matt Asay stated “Developers don’t want to be bothered with licensing uncertainty. So, to Sourcegraph’s CEO [the Fair Source author] who claims ‘It’s better to be 90% open than 10% open,’ I’d respond, ‘No, it’s really not. Both are lame. Go open or go closed, but don’t confuse developers with a Milquetoast version of open source'” <http://www.techrepublic.com/article/fair-source-licensing-is-the-worst-thing-to-happen-to-open-source-definitely-maybe/>.
Federally sponsored developers (or any organization) seeking to innovate, lower costs, and provide public good should ensure that the software under consideration carries an OSI Approved Open Source License. Without an OSI approved license, access to custom software code developed for the Federal Government would actually be reduced, as potential adopters and contributors within each agency or department will need to individually assess if the software freedoms they expect are actually present, or if the software simply—and fraudulently—carries an inauthentic “open” label. Indeed, fauxpen source software would defeat the policy’s goal to “deliver information technology (IT) and software solutions to better support cost efficiency, mission effectiveness, and the consumer experience with core Government programs” (Line 5, Federal Source Code Policy). The cost, time and expertise incurred by Federal Agencies and Departments to assess if software is actually open source, is mitigated through the OSI License Review process and OSI approved license certification. Without such, evaluating how an unknown (i.e. non-OSI approved) license may impact an agency and/or department’s access, use, modification, and distribution will become an additional burden for the Government, and any other organization that might want to participate in the project. OSI Approved Open Source Licenses, are the mechanism for “enabling Federal employees to work together—both within and across agencies—to reduce costs, streamline development, apply uniform standards, and ensure consistency in creating and delivering information” (Line22, Federal Source Code Policy). The United States Government can be sure that “OSI Approved” on a license means it’s safe to collaborate.
Another benefit of using the OSD as a standard for licensing, is in building community with both developers who contribute, and other projects who integrate. Per the Federal Source Code Policy, we agree, “Communities are critically important to the long term viability of open source projects.” The OSI License Review Process and resulting OSI approved licenses are the enabling factors that allow open source communities to form and leverage peer development. OSI Approved Open Source Licenses would allow “agencies to develop and release code in a manner that:
- fosters communities around shared challenges;
- optimizes the ability of the community to provide feedback on, and make contributions to, the code, and;
- encourages Federal employees and contractors to contribute back to the broader OSS community by making contributions to existing open source projects.”
However, without such a standard, the opportunities and restrictions of Federally sponsored code development will not be readily understood by potential community members. Worse yet, some may find any unique conditions associated with code released under a non OSI license as contradictory—or even conflicting—with existing OSI approved licenses.
Of particular note, using an existing standard—specifically, the OSD—aligns with and promotes the key community principles of the Policy:
- “Leveraging existing communities” (Line 262, Federal Source Code Policy ) is best achieved by acknowledging existing norms and working with current standards—the OSI, OSI licenses and OSD are recognized and respected by these communities.
- “Open development,” (Line 267, Federal Source Code Policy) is guaranteed through the OSD, which states, “Open source doesn’t just mean access to the source code,” but provides affordances that ensures, as required in the Policy, “an environment in which open source code can flourish and be repurposed,” for example:
- “shall not restrict any party from selling or giving away the software” (Criteria !, OSD),
- “allow modifications and derived works” (Criteria 3, OSD),
- “may no discriminate against any person or group of persons or against fields of endeavor” (Criteria 5 & 6, OSD),
- “must not be specific to a product, must not restrict other software and must be technology neutral” (Criteria 8, 9 & 10, OSD).
The OSI strongly recommends identifying only software with an OSI approved license as open source software, recognizing the Open Source Definition as the standard for assessing open source licenses, and the OSI’s License Review Process as the sole means for certification.
Specific Comments: Suggested modifications to ensure OSI Approved Licenses are referenced.
LINE 6: “Each year, the Federal Government spends more than $9 billion on software through more than 50,000 transactions. A large portion of Government software—including proprietary, open source, and mixed source options—is commercially-available “off the shelf” (COTS) software that is developed and owned by either private vendors or an open source provider, requiring no additional custom code to be written for its use in the Federal Government.”
COMMENT: Clearly the Federal Government has detailed policies and practices for the acquisition of software. While it may be beyond the scope of the Policy, the OSI would recommend developing/amending procurement practices to include the evaluation of software distributed with an OSI Approved Open Source License. Often open source software options do not receive the benefit of review as they may not be known. Without sales and marketing teams, like those of proprietary options, the Federal Government may not be aware of all possible solutions. Requiring Federal Agencies and Departments to include references to open source options throughout the procurement process would extend the knowledge of open source options, enhance the review process, and ensure equitable consideration of all possible solutions.
LINE 33: “While the benefits of enhanced Federal code reuse are significant, additional benefits can accrue when code is also made available to the public as Open Source Software (OSS).”
COMMENT: In oder to ensure that the full benefits of open source software are realized through the Policy, we recommend editing the line to state, “…when code is also made available to the public through an OSI (Open Source Initiative) Approved Open Source License.” Indeed, these benefits (higher quality, better reliability, greater flexibility, lower cost, and an end to lock-in) exist because the Open Source Definition enables them.
LINE 35: “Making code available with an OSS license can enable continual improvement of Federal code projects when a broader community of users implements the code for its own purposes and publishes bugs and improvements.”
COMMENT: Recommend the Policy state, “Making code available with an OSI (Open Source Initiative) Approved Open Source License can enable…”
LINE 38: “A number of private sector companies have already shifted some of their software development projects to an open source model, in which the source code of the software is made broadly available to the public for inspection, improvement, and reuse.”
COMMENT: Recommend the Policy state, “…shifted some of their software development projects to include an OSI (Open Source Initiative) Approved Open Source License, in which the source code…”
LINE 124: “If a covered agency’s alternatives analysis concludes that no existing Federal solution efficiently and effectively meets its operational and mission needs, a covered agency must subsequently explore whether an appropriate COTS solution is available.”
COMMENT: We would recommend that the Policy include the means for (i.e. permit) covered agencies to procure software distributed with an OSI Approved Open Source License, even if there is an existing solution for which the Government holds an appropriate license or ability to reuse. For example, in addition to the condition that allows procurement if an existing solution is not available, “If a covered agency’s alternatives analysis concludes that no existing Federal solution efficiently and effectively meets its operational and mission needs or is only available distributed with a proprietary license, a covered agency must subsequently explore whether an appropriate solution with an OSI Approved Open Source License is available.”
LINE 157: Require delivery of the underlying custom source code, associated documentation, and related files from the third-party developer or vendor to the Federal organization (including build instructions and, when applicable, software user guides, other associated documentation, and automated test suites);
COMMENT: Simply requiring that the third party developer or vendor assign an OSI Approved Open Source License would ensure these requirements are met.
LINE 162: Secure unlimited rights to the custom source code, associated documentation, and related files—which includes the rights to reproduction, reuse, and distribution of the custom source code, associated documentation, and related files across the Federal Government
COMMENT: Again, simply requiring that the third party developer or vendor assign an OSI Approved Open Source License would ensure these requirements are met. In addition, the Government agency (and all those across the Federal Government) would benefit from a larger pool of potential developers/contributors, enabling non-government organizations to also participate in the project, thus amplifying the benefits of open source software development.
LINE 170: Securing Federal Government-wide reuse rights for custom code is a critical first step in gaining efficiencies in Federal software purchasing; however, without broad and consistent dissemination of the code across the Federal Government, these efficiencies cannot be fully realized. Therefore, in addition to securing the rights discussed above, covered agencies must make custom-developed code available to all other Federal agencies.
COMMENT: As previously suggested, requiring that the third party developer or vendor assign an OSI Approved Open Source License would ensure this requirement is met. And as suggested above, all Government agencies would benefit from a larger pool of potential developers/contributors where non-government organizations could to also participate in the project, thus amplifying the benefits of open source software development.
LINE 184: Similarly, when properly implemented and documented, releasing code as open source can benefit Federal agencies by allowing professional communities of practice to develop around software libraries and Application Programming Interfaces (APIs).
COMMENT: Here we would recommend stating explicitly “releasing code with an OSI Approved Open Source License” to ensure alignment with industry standards.
LINE 218 : Federal Government and beyond can result in, among other things, enhancements to code quality and security as a result of public scrutiny of open source code.
COMMENT: Here we would recommend referencing code carrying an OSI approved license, for example, “…security as a result of public scrutiny of code distributes under an OSI Approved Open Source License.”
LINE 177: Note that although Government-wide reuse of custom-developed code shares some of the same benefits as OSS, it does not meet the definition of OSS and should therefore not be mislabeled as such.
COMMENT: In what ways does the Government-wide reuse of custom-developed code differ from the affordances offered through the OSD? Establishing another set of criteria for code development and distribution within the Government will add to ambiguity and confusion among the software development community. Organizations will be required to invest significant resources in assessing each release of code and any accompanying custom/one-off licenses to ensure they have the ability to use, modify and/or redistribute such code. Defaulting to OSI Approved Open Source Licenses would remove this burden and increase the pace of development, sharing, and innovation.
LINE 184: Similarly, when properly implemented and documented, releasing code as open source can benefit Federal agencies by allowing professional communities of practice to develop around software libraries and Application Programming Interfaces (APIs).
COMMENT: Suggest modifying the line to state, “…releasing code with an OSI Approved Open Source License…” to ensure constancy and continuity with expectations within the open source community as stated in the following line, “This collaborative atmosphere makes it easier to conduct software peer review and security testing, to reuse existing solutions, and to share technical knowledge.”
LINE 229: Each covered agency shall release at least 20 percent of its newly-developed custom code each year as OSS.
COMMENT: We would suggest an update of the Policy language to require each covered agency to release at least 20 percent of its newly-developed custom code each year with an OSI Approved Open Source License. In addition, we would hope that the Policy could include a larger percent, but recognize that an iterative process might help Federal Agencies and Departments transition. Perhaps including in the Policy methods and metrics for increasing the amount of code released could be of benefit?
LINES 458 : Open Source License: OSS is often associated with a license that details the terms and conditions governing the intellectual property rights of the software and its associated source code. These licenses specify how a particular work may be reproduced, modified, or used as a component of a larger system or as a standalone piece of software. (49)
49. As of the publication date of this policy, a valid open source license is one that is approved by the Open Source Initiative (https://opensource.org/licenses). Further licensing considerations, including suggested licenses, will be provided via Project Open Source.
COMMENT: As all licenses, “detail the terms and conditions governing the intellectual property rights of the software and its associated source code,” we feel it would be best to unambiguously denote the specific differences (affordances) of open source software licensing as made possible through the OSD. This is best conveyed by specifically stating, for example, “OSS is software distributed with a license certified by the Open Source Initiative that details the terms and conditions… “
In addition, the line “Further licensing considerations, including suggested licenses, will be provided via Project Open Source,” is confusing and will raise concerns among potential collaborators, such as:
angst among possible adoptors and contributors about investing the required resources to fully assess these new, “suggested licenses'” terms and conditions;
doubt whether the new, “suggested licenses” actually provide all of the freedoms of a community standard OSI approved license, and;
fear over license compatibility with other known OSI approved licenses.
We would strongly recommend working with the OSI and our License Review process over creating any new licenses or process for licensing.
LINE: 463: Open Source Software (OSS): Software that can be freely accessed, used, changed, and shared (in modified or unmodified form) by anyone. OSS is often distributed under licenses that comply with the definition of “Open Source” provided by the Open Source Initiative (https://opensource.org/osd). (50)
50. This definition is current as of the publication date of this policy. For future guidance regarding this definition, please refer to Project Open Source.
COMMENT: We are pleased that the Policy includes a quote from the OSI FAQ, “What is “Open Source” software?” https://opensource.org/faq#osd. Further, rather than stating, “OSS is often distributed under licenses…”, we suggest also aligning this statement with the OSI FAQ:
Can I call my program “Open Source” even if I don’t use an approved license?
Please don’t do that. If you call it “Open Source” without using an approved license, you will confuse people. This is not merely a theoretical concern — we have seen this confusion happen in the past, and it’s part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem. <https://opensource.org/faq#avoid-unapproved-licenses>.
Thank you for the Opportunity
On behalf of the OSI Board of Directors, I would like to thank you very much for your good work in developing a thoughtful and comprehensive Policy as well as extending to the public the opportunity to review and comment on your work. We hope that our experience as the founders of the open source software movement, and industry recognized authority in open source incensing, can provide the White House Office of Management and Budget some additional insights for further consideration. If we can help in any way, please know we stand ready to assist you.
Best of luck moving forward,
General Manager and Director,
Open Source Initiative,
855 El Camino Real, Ste 13A, #270
Palo Alto, CA 94301
- Thu, 26 May 2016 10:33:39 +0000: One ad-free day: Three UK to block adverts across network in June – The Register – Networks
24-hour trial takes a load off (for the operator)
Mobile operator Three is pushing ahead with plans to block ads on its network in the UK during a one-day trial next month.…
- Thu, 26 May 2016 00:47:23 +0000: Florida man, Chinese biz fined $48k, $35m on mobe signal jam raps – The Register – Networks
Wham, jam, pay Uncle Sam
The US Federal Communications Commission (FCC) has fined a Florida chap and a Chinese business over cellphone jamming boxes.…
- Wed, 25 May 2016 20:41:27 +0000: Big Cable uses critics’ own arguments to slam set-top box shake-up – The Register – Networks
Where exactly should the FCC’s authority stop?
Analysis Amid a battle to end Big Cable’s $20bn annual windfall from rented set-top boxes, the industry has hit on a novel strategy: use its opponents’ own arguments against them.…
- Fri, 06 Sep 2013 16:24:32 +0000: Two Drafts in Last Call: N-Triples, N-Quads – W3C News
The RDF Working Group has published two Last Call Working Drafts:
- N-Triples. N-Triples is a line-based, plain text format for encoding an RDF graph. Comments are welcome through 14 October.
- N-Quads. N-Quads is a line-based, plain text format for encoding an RDF dataset. Comments are welcome through 14 October.
Learn more about the Semantic Web Activity.
- Thu, 05 Sep 2013 20:26:31 +0000: Updated Techniques for Web Content Accessibility Guidelines (WCAG) 2.0 and Understanding WCAG 2.0 – W3C News
The Web Content Accessibility Guidelines Working Group today published updates of two Notes that accompany WCAG 2.0: Techniques for WCAG 2.0 and Understanding WCAG 2.0. (This is not an update to WCAG 2.0, which is a stable document.) For background, important information about techniques, and opportunities to contribute to future updates, please see the Understanding Techniques for WCAG Success Criteria e-mail. Read about the Web Accessibility Initiative (WAI).
- Thu, 05 Sep 2013 20:16:36 +0000: Last Call: Media Source Extensions – W3C News