Open Source Initiative

Syndicate content
Updated: 3 hours 26 min ago

Assume Good Faith

Fri, 2017-07-21 10:03


You feel slighted by a comment on a mailing list, or a forum post has failed to be moderated live. How should you react?

A recent exchange on a user forum caught my eye, one that’s typical of many user interactions with open source communities. Someone with a technical question had apparently had the answer they needed and to help others in the same situation had posted a summary of the resolution, complete with sample code. When they came back later, the summary was gone.

I’ve no idea why this happened. It may have been a system issue, or an administrative error, or the user himself may have accidentally deleted it without realising. It’s even remotely possible an intentionally malicious act took place. Without more information there is no way to know. For the self-aware mind, responding to this situation is a matter of choice.

So how did the user in question respond? Well, he decided the only possible explanation was malicious deletion. He posted an angry demand that his account be deleted and assumed more malice when this was “ignored” (after 3 days, including a weekend, having posted the demand at the end of a comment in a user forum…)

No matter how you look at it, I don’t think that was a very smart choice. Given he was posting in a busy user forum managed by volunteers, and that this was his first post, the chance any action would be intentionally directed at him is vanishingly small. He would have been far smarter to put his ego on hold and take a lesson from driving principle of Wikipedia. “Assume Good Faith“.

That’s great advice in all communities of volunteer strangers. The things that happen usually have a great explanation, and the motivations of volunteers are almost always to make things better. So when a thing happens, or something is said, that you don’t understand or can’t explain, the best assumption to make is that it has happened “in good faith”. More significantly, when you think you do understand the motivation, over-ride your instinct and choose to respond as if it was good faith!

How to assume good faith

The chain of assumptions to make if you assume good faith might go like this:

  • The thing was probably your mistake.
  • If it wasn’t, then it was an unintentional defect.
  • If it wasn’t, then it was the act of someone with more information than you acting correctly.
  • If it wasn’t, then the person was acting in the belief they were correct but with imperfect information.
  • If not, then they were inexperienced.
  • But whatever the explanation, in the unlikely event you ever find out, don’t assume it was an act of intentional malice!

Maybe you can’t let any of the assumptions in that chain go. Maybe the person really is an idiot; it happens. All the same, an angry response is still not helpful, either to you or to the Community. Open source communities only thrive when a critical mass of participants choose to assume good faith in every interaction. The assumption is very occasionally misplaced, but even when that’s so it’s almost always better to respond by assuming good faith anyway.

That doesn’t mean it’s wrong to apply corrections. Good intentions do not guarantee good actions. But correcting a thing done in good faith has a distinct character of good faith itself. The original choice to act is welcomed and valued. The explanation of the flaw in the act is good-natured, clear, never patronising. The correction is generous. The whole thing is warm and seeks to build the confidence of the contributor.

It’s a lesson the detail-oriented among us need to remember (I include myself in that). The overwhelming majority of community actions are intended well. Treating them as such — even when they are wrong — will grow individuals and the community with them.

This article originally appeared on "Meshed Insights" and was made possible by Patreon patrons.
Image credit: CC0 / Public Domain via Max Pixel

Categories: FLOSS Research

Why OSI License Approval Matters

Fri, 2017-07-14 10:59


Individual judgment about the presence of software freedom in a license is not the same as community consensus expressed through OSI approval.

Does it really matter if a copyright license is OSI Approved or not? Surely if it looks like it meets the benchmark that’s all that matters? I think that’s the wrong answer, and that OSI license approval is the crucial innovation that’s driven the open source revolution.

“Open Source” describes a subset of free software that is made available under a copyright license approved by the Open Source Initiative as conforming with the Open Source Definition. Having a standards body for licenses — one which ratifies the consensus of an open community of license reviewers — saves individuals from needing to each seek out a legal advisor to tell them whether a given license does in fact give them the rights they need to build or deploy the software they want. By providing easy certainty, open source gives people permission in advance to meet their own needs and innovate with technology.

The only arbiter of OSD compliance is the license review process conducted collaboratively by the open source community and summarized and ratified by the OSI Board of Directors. Others have no role outside this process and are not entitled to assert that a non-approved license satisfies the OSD. As such, licenses that have not received OSI approval don’t satisfy the process and can’t be considered open source.

The strength of OSI’s approach is that it is objective; a license is either on the approved list or it is not. Licenses on the list are known to give permission in advance and unlock software freedom; those not on the list cannot be guaranteed to do either. The FSF uses a subjective approach that encourages speculation about whether a license is “free”. Meanwhile there are many with vested interests in diluting free and open source software who want a subjective approach where every individual may act as their own arbiter. Despite these pressures, it’s the OSI’s approach that has made open source succeed.

That’s not because a legalistic tick-in-the-box is really interesting. Rather, it’s because developers can gain certainty as to whether they can use a project simply by checking its approval status. No-one has to be asked for permission or clarification. Significantly, there’s no need to retain a lawyer just to check the license is in fact safe to use.

It’s easy to get overwhelmed by all the details of the many open source licenses, losing sight of the reason they are important. They’re important because every open source license guarantees the freedom to innovate without seeking permission first. OSI approval means you have the unconditional right to use the software in question for any purpose (sometimes calls “freedom zero”). You also have an unconditional right to make new software based on that software for your own use, and a conditional right to share the software — modified or not — with other people. The final case comes with some complexities beyond the scope of this article, especially for copyleft licenses.

That freedom to innovate, unlocked by the permissions the OSI-approved license guarantee in advance, is the powerhouse of open source. Developers know they can incorporate open source components without seeking legal advice. Users know they can deploy the software with the confidence that they have a license and won’t be persecuted by rent-seeking proprietary software companies. Together, this liberty has realized the potential of free software and propelled open source to dominance over the course of the last decade.

(A variant of this article was published in the Linux Voice section of issue 199 of Linux Magazine, June 2017)

This article originally appeared on "Meshed Insights" and was made possible by Patreon patrons.
Image credit: CC0 / Public Domain via Max Pixel

Categories: FLOSS Research

Permissive and Copyleft Are Not Antonyms

Fri, 2017-07-07 13:16


Using the term “permissive” as an antonym to “copyleft” – or “restrictive” as its synonym – are unhelpful framing. Describe license reciprocity instead.

Some open source licenses implement a clever hack invented by Richard Stallman where, as a condition of the copyright license, anyone creating derived versions has to agree they will license the new version the same way as the original. In a play on words, this concept is called “copyleft” and many open source licenses implement this hack.

In its strongest form, the “copyleft” idea can place a condition on the licensing of all the other code compiled together to make the eventual binary executable program. Complying with this requirement can prevent use of business models that deny software freedom to the end user; as a consequence, many commercial software developers avoid the strongest forms of copyleft licensing.

There are less stringent forms of copyleft. Licenses like the MPL (Mozilla Public License) only require individual files that are modified to be licensed under the same license as the original and don’t extend that requirement to other files used to build the executable. The Eclipse Public License (EPL) has a copyleft provision that’s triggered by distribution of the source code. These scope-restricted variants are all described as “weak copyleft.”

In discussing these licensing approaches with clients, I’ve often found that these terms “strong copyleft” and “weak copyleft” lead to misunderstandings. In particular, developers can incorrectly apply the compliance steps applicable to one “weak” license to code under another license, believing that all such licenses are the same. As a consequence, I prefer to use different terms.

Instead of “copyleft” use “reciprocal licensing”

First, I try to address the challenges introduced by the clever, often unfamiliar term “copyleft.” The demonisation of copyleft by certain factions in the open source movement — who may even erroneously term such licenses “restrictive” — has made it appear more problematic than it really is. Instead, I explain that the communities involved have norms based of reciprocal behaviour and expect those working with their code to share with others the same freedom to innovate as they have received.

Leading licensing lawyer Eben Moglen (key co-creator of the modern GPL) explains that open source licenses embody the norms of the communities that use them. They are in many ways the “constitution of the community,” so the embodiment of norms of reciprocity is to be expected. I refer to this aspect of the license as “reciprocal licensing” in an effort to acknowledge the use of copyleft to express the community expectation of reciprocity. I’ve found this term leads to less confusion.

Instead of “strong” or “weak” copyleft, describe the reciprocity scope.

Second, I have found that the terms “strong” and “weak” are not well understood and less well defined. What really matters to developers is the expected scope of the reciprocity by the community that’s involved. This does not always mean contributing code to a project; for example, the GPL only requires that a developer offers to make code available on the same terms as the original, for a limited time per release. But reciprocity does mean that consistent licensing must be maintained.

This concept helps my clients in the case of the LGPL. That license is often described as a “weak copyleft” license since it allows combination of the resulting binary with non-GPL-licensed works (unlike the GPL itself). But the “weak” categorization is unhelpful as it means different things in different contexts.

LGPL is not “weak” in the same way MPL is, for example. Code from an LGPL project itself is fully reciprocally licensed at a project level. Any code borrowed from it for other uses as well as any alternative uses of the project itself are expected to be fully licensed under the same LGPL. Within the project itself, LGPL is “strong copyleft” just like GPL code, but the resulting executable does not necessarily have “strong copyleft” requirements – it’s effectively non-reciprocal in many uses.

I prefer to categorize reciprocal licenses by the scope and nature of the expected reciprocity. Licenses like GPL and EUPL set the scope of the expected reciprocity to include any code needed to create the resulting project binary, so I describe these as “project-scoped reciprocal licenses.” This categorization proves helpful with LGPLv3, which is a project-scoped reciprocal license with an exception limiting the boundary of the project.

Licenses like MPL set the scope of the expected reciprocity to the individual source files within the project, not the whole project collectively. If you change a file that’s part of the project, or reuse code from a file in the project in a new codebase, the resulting file must be licensed the same way as the original file, but there are no requirements placed on other files combined together to create new executables. I refer to these as “file-scoped reciprocal licenses.”

Instead of “permissive” use “nonreciprocal”

Thirdly, licenses like the MIT, BSD, and Apache licenses are sometimes described as “permissive.” That’s a bad word to use to differentiate any open source license. All open source licenses are predominantly permissive as they permit unconditional use, unlike proprietary licenses. Just as with reciprocal licenses, the communities involved have different expectations and embody them in their licenses. While they may not include reciprocity, they may still include burdensome terms.

For example, so-called “permissive” licenses may still include specific actions regarding attribution, or grant expansive patent licenses. They may also fail to include any terms concerning patents, creating risk. These attributes may also affect the business models a client can use, just in different ways to reciprocal licenses. Consequently, I find it more helpful to describe them as “non-reciprocal licenses” so that the classification is clearly limited to just the reciprocity characteristics of the licenses.

In practice, I have found that these three terms — project-scoped reciprocal, file-scoped reciprocal, and nonreciprocal –- highlight what matters most to developers and avoid unintentionally confusing the issue. I recommend their use instead of “permissive” and “weak/strong copyleft” or “restrictive”.

(A shorter version of this article was first published in InfoWorld, November 2013)

This article originally appeared on "Meshed Insights" and was made possible by Patreon patrons.
Image credit: CC0 / Public Domain via publicdomainpictures.net

Categories: FLOSS Research

OSI extends support to OW2 as Associate Organization.

Sun, 2017-07-02 21:43


OW2, the global community for open source infrastructure software and application platforms, and the Open Source Initiative (OSI), the global steward of the Open Source Definition, announced at OW2con’17 that OSI has extended our support to OW2 as an associate member.

While both the OSI and OW2 have been working for yeas to promote software freedom, extending the partnership between the two organizations now, signifies several recent developments in shared initiatives:

  • This year's OW2con’17 central theme was “New Challenges of Mainstream Open Source Software”, focusing on open source software as a viable and a mature option for corporate and government end-users. Both OW2 and OSI are increasing their efforts to help interested and adopting organizations understand the benefits of open source software, and to support decision makers through identification, and implementation.
  • Simon Phipps, Board Director of the Open Source Initiative, is providing a keynote at OW2con’17 highlighting Open Source in its the Third Decade. OSI was established in 1998, and with it the term "open source software" to describe software licensed to enable collaboration around free software. 2018 consequently sees the start of the third decade of open source. What changes will we see? What principles can guide us?
  • Cedric Thomas, CEO of OW2 offered, “As OW2 is celebrating its 10th anniversary, the Open Source Initiative is about to celebrate it's 20th. I’m looking forward to see our teams, members and communities working more closely. Together, we can address more market needs while developing new synergies”.
  • Patrick Masson, Director and General Manager of the Open Source Initiative, acknowledges: “If indeed, as many now say, "open source has won", then we all should thank OW2 for playing their part over the past 10 years as a visionary, innovator and leader. All the best for the next ten”.
  • This partnership will bring OSI and OW2 members the benefits of a greater technical alignment of the two organizations, joint workshops and community events. For the latest opportunities, please visit our websites.

    About the Open Source Initiative

    The Open Source Initiative (OSI) is a California public benefit corporation, with 501(c)3 tax-exempt status, founded in 1998. The OSI is the stewards of the Open Source Definition (OSD) and the community-recognized body for reviewing and approving licenses as OSD-conformant and is also actively involved in Open Source community-building, education, and public advocacy to promote awareness and the importance of non-proprietary software. OSI Board members frequently travel the world to attend Open Source conferences and events, meet with open source developers and users, and to 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. You can learn more about the OSI at opensource.org or by emailing, osi@opensource.org

    About OW2

    OW2 is an independent industry community dedicated to developing open source code infrastructure (middleware and generic applications) and to fostering a vibrant community and business ecosystem. The OW2 Consortium hosts some one hundred technology projects, including ASM, Bonita, Chameleon, CLIF, DocDoku, Easybeans, Emerginov, Fractal, FusionDirectory, JOnAS, JORAM, JOTM, LemonLDAP:NG, Lutece, PetalsESB, Prelude, ProActive, SAT4J, Spagic, Spago4Q, SpagoBI, Talend Studio, Telosys, WebLab, XWiki. Visit www.ow2.org

Categories: FLOSS Research

Growing The Community

Tue, 2017-06-20 23:01


How can you grow an open source community? Two blog posts from The Document Foundation (TDF) illustrate a proven double-ended strategy to sustain an existing community.

Since it was established in 2010, the LibreOffice project has steadily grown under the guidance of The Document Foundation (TDF) where I’ve been a volunteer — most lately as a member of its Board. Starting from a complex political situation with a legacy codebase suffering extensive technical debt, TDF has been able to cultivate both individual contributors and company-sponsored contributors and move beyond the issues to stability and effectiveness.

What made the project heal and grow? I’d say the most important factor was keeping the roles of individual and company contributions and interests in balance, as these two posts illustrate.

Individual Contributors

The first priority for growth in any open source project is to grow the individual contributor base. TDF has used a variety of techniques to make this possible, many embodied in first of the two illustrative posts, announcing another Contributor Month declared for May 2017 which asked people to:

  • Help to confirm bug reports
  • Contribute code
  • Translate the user interface
  • Write documentation
  • Answer questions from users at ask.libreoffice.org
  • Spread the word about LibreOffice on Twitter

As part of the event the co-ordinator promised to send specially-designed stickers to all contributors, providing a positive reinforcement to encourage people to join in and stay around.

Equally importantly TDF provides introductions to many contribution types.  There is a well-established getting started guide for developer contributors, including the well-established “Easy Hacks” list of newbie-friendly things that need doing. There’s also a good introductory portal for translators/localizers.

All of this has been undergirded by sound technical choices that make joining such a complex project feasible:

  • Reimplementing the build system so you don’t have to be a genius to use it
  • Extensive use of automated testing to virtually eliminate uncalled code, pointer errors and other mechanically-identifiable defects
  • An automated build system that stores binaries to allow easy regression testing
  • Translation of comments into English, the project’s language-of-choice (being the most common second language in the technical community)
  • Refactoring key code to use modern UI environments
Commercial Opportunity

Secondly, TDF has operated in a way that encourages the emergence of a commercial ecosystem around the code. That in turn has led to the continued employment of a substantial core developer force, even in the face of corporate restructuring.

LibreOffice has a very large user base — in the double-digit millions range worldwide — and many of those visiting the download page make financial donations to help the project. That’s a wonderful thing for a project to have, but it turns out that having money is not necessarily an easy blessing. It needs spending, but that has to be in a way that does not poison the contributor community.

Rather than hiring staff to work on the software, the project identifies areas where unpaid volunteers are not likely to show up and its Engineering Steering Committee proposes a specification. The Board of Directors then creates a competitive tender so that individuals or companies can earn a living (and gain skills) making LibreOffice better while still retaining the collaborative spirit of the project. Doing this builds commercial capability and thus grows the overall community.

So the second post is a sample tender, this one to do some unglamorous refactoring work to update the SVG handling. TDF is likely to receive a number of costed proposals and the Board will make a decision how to award the work based on the greatest community benefit — a combination of optimum cost, involvement of community members, nature of the bidder and more. The result is a community contributor fairly compensated without creating a permanent TDF staff role.

Balance Yielding Benefit

As a result of this and other carefully-designed policies, the LibreOffice project now has a developer force in the hundreds, companies whose benefits from LibreOffice lead to them making significant contributions, a reworked and effective developer environment with automated testing to complement the test team, and one of the most reliable release schedules in the industry.  This means new features get implemented, bugs get fixed and most importantly security issues are rapidly resolved when identified.

This is what OpenOffice.org became when it left the commercial world. The early controversies have passed and the project has a rhythm that’s mature and effective. I think it’s actually better now than it was at Sun.

This article originally appeared on "Meshed Networks" and was made possible by Patreon patrons.
Image Credit, Simon Phipps. 2017. CC-BY-ND.

Categories: FLOSS Research

OW2 Consortium: Building Beyond Europe

Thu, 2017-06-15 08:12


This year marks the 10th anniversary of OW2, and the organization is celebrating during its annual conference, on June 26-27, in Paris, France. OSI GM Patrick Masson sat down with Cedric Thomas, CEO of OW2 to learn more about the foundation, it’s accomplishments over the past 10 years, and what’s in store for the anniversary celebration.

The Open Source Initiative (OSI) Affiliate Membership Program is an international who’s who of open source projects, advocates, and communities: Creative Commons, Drupal Association, Linux Foundation, Mozilla Foundation, Open Source Matters (the foundation supporting Joomla), Python Software Foundation, Wikimedia Foundation, Wordpress Foundation and many more. Open source enthusiasts outside Europe may not be as familiar with another OSI Affiliate Member, OW2, however its impact on open source development and adoption across the EU has been significant.

“...open source is not only a great way to develop great software collaboratively,
but also a new way of doing business in the software industry.”

Patrick Masson: Can you tell me a little bit about OW2 for those who may not be familiar with the organization?

Cedric Thomas: OW2 is a non-profit, founded in 2007, dedicated to the development of enterprise-level open source software. We are very proud to be celebrating our tenth anniversary this year. OW2 inherited a repository of open source middleware solutions called ObjectWeb, that was supported by Inria], the French Institute for Research in Computer Science and Automation, and Bull ATOS Technologies. We launched OW2 with the vision that open source is not only a great way to develop great software collaboratively, but also a way of doing business in the software industry.

OW2's technical focus is on software that is more related to back-end technical excellence than to customer-facing competitive advantage. It's the kind of software that can be developed collaboratively by different companies even if they are competitors. We focus on infrastructure software for distributed business processes. Our scope encompasses middleware and application platforms for the management of business processes (BPM), business intelligence (BI), big data, content (CMS), identity and access, collaboration (wiki, chat) and cloud computing. We also welcome projects that help develop and manage these distributed systems. Our code base also has tools and frameworks for development, testing and workload simulation.

Masson: Is it fair to say OW2 is primarily working with organizations in Europe? What are some of the benefits you've found working across the EU?

Thomas: OW2 was founded by members from all over the world: the US, Brazil, China and Europe— we are a global organization. We have no physical offices, we live on the web, so to speak, and our team has been global from the beginning. We have strong ties with open source communities in Brazil and China for example. But you are right, after ten years it is fair to say that, although our strategy is global, we have the most traction in Europe, with almost 2/3 of our new individual members last year (in 2016) coming from Europe. It is a big market with a keen interest in open source. OW2 is easily accessible for SMEs and collaborative projects, and we are regularly invited to take part in publicly financed R&D projects with which we have real experience. For many, we have become the de facto EU-driven open source organization.

“...we live on the web, so to speak, and our team has been global from the onset...
we have become the de facto EU-driven open source organization.”

Masson: What about challenges?

Thomas: There are lots of very good open source developers in Europe, but there are very few software industry leaders. That's clearly our main challenge. It's a geography of good open source contributors and clever consumers, but the software industry leadership is not in Europe. That has an influence on both software vendors and users. Many European vendors may develop world-class technologies while being, in fact, followers from a business point of view. On the user side, many decision makers are conservative, they seek some sort of protection in proprietary software. Another challenge is that Europe remains a fragmented market, as most open source SMEs concentrate on their home market, deriving perhaps only 20% of their revenue from other countries. It's a question of culture, of professional networks and, of course, language. And because of that fragmentation, these SMEs find it difficult to reach a critical mass that could make them industry leaders.

Masson: What types of activities is OW2 working on that expand beyond Europe?

Thomas: As of today, “Beyond Europe” for OW2 really means Brazil where we support a fledgling local chapter, and China where our members run a local chapter and organize an annual programming contest for students. I know there is significant potential for OW2 in Africa, the Middle-East and Russia, but we currently do not yet have the bandwidth to properly look after these markets. We have a significant number of visitors and downloads from the US, and this is the reason why we think it is important for OW2 to take part in events that are both local and global such a OSCON and the OpenStack Summit.

Masson: In the 10 years of OW2's work, what do you think have been the greatest challenges for open source software and communities, not just OW2, but the open source movement?

Thomas: Well, I think the past ten years have been rather good for open source. It’s now recognized as the primary mechanism for collaborative innovation. In addition, the proliferation of non-profit organizations, or foundations, dedicated to projects or technologies, is an excellent illustration of the fantastic momentum open source has seen in recent years. It doesn't mean there haven’t been challenges. As I said, we see open source as a way to do business, but that doesn't mean you can do whatever you want. From that perspective I see two principal challenges. On one hand, there is the issue of defending the integrity of the open source model against all sorts of opportunists who take advantage of it with business strategies based on open core licensing and user lock-in tactics. On the other hand, there is making open source more professional and economically sustainable in a context characterized by a flurry of open source projects, many of which are amateurish and short-lived.

"the Technology Council is also careful not to accept what we call 'crippleware'
...software that is useless unless complemented by additional proprietary software."

Masson: How has OW2 worked to address those challenges?

Thomas: We have addressed these issues through our governance, first by how we accept projects in our code base, and second, how we help them improve quality. Firstly, our Technology Council has always been very careful with the projects accepted in the OW2 code base. Right from the beginning we have ruled out purpose-made or vanity licenses. Our projects must publish their software under a license endorsed by the Open Source Initiative. Period. But the Technology Council is also careful not to accept what we call “crippleware” i.e. software that is useless unless complemented by additional proprietary software. Secondly, five years ago we launched a quality program aimed at helping project leaders better manage their projects and building trust among users for software in the OW2 code base. Last year we launched the second generation of our quality program: the Open Source Capability Assessment Radar (OSCAR).

"OSS has to prove its worth to conventional business managers
who are far from free software advocates."

Masson: What do you think are the most exciting opportunities for the future of open source software, and how will OW2 play a part.

Thomas: Open source software is going mainstream, and this brings a whole range of new challenges to the open source ecosystem. Even OW2's market sweet spot may be shifting. As I said, OW2 was born out of enterprise information system infrastructure where software is not dependent on a company's vertical sector – a CMS or an ESB works practically the same way whether it be a bank or a hospital – and where sharing and re-use across all sectors brings critical mass and maximizes economies of scale. But, as it becomes increasingly mainstream, OSS expands into new territories where its advantages are not quite so obvious. For example, in going mainstream OSS has to prove its worth to conventional business managers who are far from free software advocates. We are currently leveraging the experience gained through our quality program by developing a transposition of NASA's Technology Readiness Levels in the business world of open source. We will introduce the OW2's Market Readiness Index at OW2con, our annual conference, in June. It will bring value to our projects and stability and predictability for open source decision makers. I see another opportunity in the IoT world: it is still pretty much structured in silos, where software is dependent on usage specific hardware and standards and where developments across different usage are not easily shared. As it matures, I expect the IoT world to become a market for horizontal platforms. This will open tremendous opportunities for an experienced organization such as OW2.

Categories: FLOSS Research

OSI Joins Internet-wide Day of Action to Protect Net Neutrality

Mon, 2017-06-12 17:57


On July 12, 2017, websites, Internet users, online communities an the Open Source Initiative will come together to sound the alarm about the FCC’s attack on net neutrality. Learn how you can join the protest and spread the word at https://www.battleforthenet.com/july12.

Right now, new FCC Chairman and former Verizon lawyer Ajit Pai has a plan to destroy net neutrality and give big cable companies immense control over what we see and do online. If they get their way, the FCC will give companies like Comcast, Verizon, and AT&T control over what we can see and do on the Internet, with the power to slow down or block websites and charge apps and sites extra fees to reach an audience.

If we lose net neutrality, we could soon face an Internet where some of your favorite websites are forced into a slow lane online, while deep-pocketed companies who can afford expensive new “prioritization” fees have special fast lane access to Internet users – tilting the playing field in their favor.

But on July 12th, the Internet will come together to stop them. Websites, Internet users, and online communities will stand tall, and sound the alarm about the FCC’s attack on net neutrality.

The Battle for the Net campaign will provide tools for everyone to make it super easy for your friends, family, followers to take action. From the SOPA blackout to the Internet Slowdown, we've shown time and time again that when the Internet comes together, we can stop censorship and corruption. Now, we have to do it again!

Learn more and join the action here: https://www.battleforthenet.com/july12

Categories: FLOSS Research

Proprietary Election Systems: Summarily Disqualified

Fri, 2017-04-28 17:06

The following was provided by Brent Turner, California Association of Voting Officials (CAVO) Secretary. CAVO, an OSI Affiliate Member.

Hello Open Source Software Community & U.S. Voters,

I and the California Association of Voting Officials, represent a group of renowned computer scientists that have pioneered open source election systems, including, "one4all," New Hampshire’s Open Source Accessible Voting System (see attached). Today government organizations like NASA, the Department of Defense, and the U.S. Air Force rely on open source software for mission critical operations. I and CAVO believe voting and elections are indeed mission-critical to protect democracy and fulfill the promise of the United States of America as a representative republic.

Since 2004, the open source community has advocated for transparent and secure—publicly owned—election systems to replace the insecure, proprietary systems most often deployed within communities. Open source options for elections systems can reduce the costs to taxpayers by as much as 50% compared to traditional proprietary options, which also eliminates vendor lock-in, or the inability of an elections office to migrate away from a solution as costs rise or quality decreases.

Like others, CAVO is opposed to AB-668 Voting Modernization Bond Act of 2018. Although this Act might help our efforts toward better, open source, election systems, the bond funds it creates—450 million dollars—can be used by California localities to procure insecure, over-priced, proprietary systems, which will only lock these communities into additional commitments (and more costs). This Act will set horrible precedent for the United States, only exacerbating the growing national security and confidence crisis surrounding elections and their outcomes.

CAVO finds it incomprehensible that an elected leader in the United States would push for funding of these systems deemed insecure by government studies. Their proprietary nature disqualifies them summarily.

Both I and CAVO are available for further information.

Best regards,
Brent Turner
Secretary, California Association of Voting Officials
www.cavo-us.org

Categories: FLOSS Research

React to React

Thu, 2017-04-27 07:36

The OSI has received several inquiries concerning its opinion on the licensing of React [1], which is essentially the 3-clause BSD license along with, in a separate file, an 'Additional Grant of Patent Rights' [2].

The Additional Grant of Patent Rights is a patent license grant that includes certain termination criteria. These termination criteria are not entirely unprecedented when you look at the history of patent license provisions in OSI-approved licenses, but they are certainly broader than the termination criteria [or the equivalent] in several familiar modern licenses (the Apache License 2.0, EPL, MPL 2.0, and GPLv3).

The 'Additional Grant' has attracted a fair amount of criticism (as did an earlier version which apparently resulted in some revisions by Facebook). There was a recent blog post by Robert Pierce of El Camino Legal [3] (which among other things argues that the React patent license is not open source). Luis Villa wrote an interesting response [4].

What do members of the license-discuss community think about the licensing of React? OSI Board Director Richard Fontana posed a few issues to the OSI's License Discuss forum (you can see the thread here):

  • does the breadth of the React patent termination criteria raise OSD-conformance issues or otherwise indicate that React should not be considered open source?
  • is it good practice, and does it affect the open source status of software, to supplement OSI-approved licenses with separate patent license grants or nonasserts? (This has been done by some other companies without significant controversy.)
  • if the React patent license should be seen as not legitimate from an OSI/OSD perspective, what about the substantial number of past-approved (if now mostly obsolete) licenses that incorporated patent license grants with comparably broad termination criteria?
  • should Facebook be encouraged to seek OSI approval for the React license including the patent license grant?

Please note, at the time of this post and discussion, Facebook was a Corporate Sponsor of the Open Source Initiative.

[1] https://facebook.github.io/react/ [2] https://github.com/facebook/react/blob/master/PATENTS [3] http://www.elcaminolegal.com/single-post/2016/10/04/Facebook-Reactjs-License [4] http://lu.is/blog/2016/10/31/reacts-license-necessary-and-open/
Categories: FLOSS Research

Volunteering at the 2017 SFBay ACT-W conference

Mon, 2017-04-17 10:48

Special guest article by Sean Roberts (@sarob). The OSI would like to thank Sean, Erich and Zack for all their help in promoting and staffing the OSI booth during the Bay Area ACT-W, and their support of open source software and women in technology. The OSI frequently reaches out to our membership and local open source software advocates to help organize and staff local events—if you're interested in volunteering too, please contact us.

What Was This

I had the privilege of volunteering for the Open Source Initiative (OSI) table at the ACT-W conference at Galvanize, San Francisco this last Saturday with Erich Clauer and Zachariah Sherzad. It was an event focused on giving women the best information on advancing in technical careers. Keynotes and talks sounded excellent on paper, but I missed out on them, as I was in the career fair part of the event for the day. There were many volunteering tables set up in the career area. OSI was one of them. Pyladies, Chicktech, Docusign, among others were there to support technical women. I answered questions about OSI and open source. There was a mix of experience levels, but most were just starting their technical careers.

What Was Happening

Everyone was networking, which is always a good practice. The energy was positive and welcoming. I was able to talk with many women on what OSI stands for and what I could help them with. Describing the benefits of open source is very enjoyable. Especially relevant there were a lot of opportunities to engage people directly. I felt my mentoring on how to join public open source teams was good and valuable information. However, I wasn’t helping with the most important need of all, a paying job.

How To Improve

I should have had a list of open source positions from all the OSI affiliates. Through the ACT-W organizers, I should have asked for digital resumes and LinkedIn URLs before the event started. As people came forward, I could have looked up their resume and matched them with possible openings. Then I could counsel them on their experience and plans.

So, I am going start working with OSI to figure out how we can add these and additional services.

Cheers!

Originally posted at sarob, April 14th, 2017, licensed under a Creative Commons Attribution 4.0 International License.

Categories: FLOSS Research

Software Freedom Advocates Invited to the Open Source Initiative's Community Social

Sat, 2017-04-01 13:41

OSI hosting a community social for the open source software community: join us for drinks, dinning and discussions.

Meadhall, Cambridge, MA April 04, 2017 -- If you're in the greater Boston, Massachusetts area on Tuesday, April 4th, the OSI Board of Directors invites you to join us and the free and open source software community for a casual evening get-together (Oh, and please feel free to bring a friend).

If you're interested in extending your open source activities, the following day the OSI will be hosting, a symposium on Open Source Software, Open Science, Open Source Hardware, and their role in innovation: "Open Source for Science + Innovation." Details can be found here.

Details for the community social...

Day/Time:
Tuesday, April 4th, 2017
8:00 PM to ???

Location:
Meadhall
4 Cambridge Center
Cambridge MA 02142

Categories: FLOSS Research