Open Source Initiative

Syndicate content
Updated: 15 hours 56 min ago

7 Things You Should Know About… Open Source Projects in Education

Wed, 2017-09-20 11:21

EDUCAUSE's 7 Things You Should Know About ...™ is a series of publications that address a diverse range of professional challenges in higher education IT, from updates on current developments to explorations of important overarching issues. In August of 2017, the organization offered insights in open source in higher education.

Halfway through the semester, Dr. Margaret Broadwater was excited by the progress her students were making in her course Open Source Software Development. Working with open source software projects and development communities gave her students hands-on experience with software development practices, technology frameworks, data structures, and product development. Students also completed installation exercises for open source projects from both developers’ and users’ perspectives, followed by finding and patching bugs in the software. Broadwater knew that her students were learning more than just how to work their way around code. In talking with students she emphasized that open source code was the heart of applications that had become ubiquitous in business and education, including Chrome and Firefox, and was the driver for software like the Apache web server, Fedora Linux, and OpenSSL. Moreover, open source had gained purchase in use by companies, organizations, and government agencies and was thus something they would need to know once they entered the workplace as software devel- opers and engineers. Broadwater knew that by working on open source projects in depth, her students were also learning about the ethos of building code in a community of developers—and, indeed, were becoming part of that community.

Broadwater had learned about open source in a summer workshop sponsored by POSSE, the Professor’s Open Source Software Experience. That meeting focused on helping instructors learn to engage students in development of free and open source software (FOSS). Broadwater learned about FOSS tools and the FOSS culture, picked up a cache of rich curricular materials, and learned pedagogical techniques for supporting student engagement in learning about open source. Another plus was that the instructor for the workshop volunteered to serve as a mentor for Broadwater’s class. Working occasionally with students via BigBlueButton, an open source web conferencing system, he helped steer learners through assignments and answered their most challenging technical questions.

By the end of the semester, Broadwater’s students had successfully learned many of the intricacies and idiosyncrasies of open source projects. Some were still learning particulars, like fixing bugs. Other students were eager to move beyond the fundamentals, and Broadwater urged them to focus on suggesting specific improvements or additions. Several students made that assignment the focus of their senior projects.

1 What is it?

Open source refers to software that can be freely used, changed, and shared. open source projects engage a community of developers who collaborate and iterate to develop, grow, and improve software. Developers can access, modify, and customize functionality, providing considerable control to organizations that implement open source software. In general, open source projects seek less expensive and more flexible paths to solutions that are not being adequately or affordably addressed by proprietary software. Typically, communities that initiate an open source project establish a set of values and governing principles concerning factors such as priorities for features, technical specifications, workflows, and how the community working on the project will make decisions. Organizations that build open source software for education include Apereo, DuraSpace, Kuali, and Moodle. The nonprofit Open Source Initiative develops standards and certifies licenses for open source code.

2 How does it work?

Colleges and universities engage in open source projects in a variety of ways. One impetus for considering open source projects is when a campus believes it can better meet its software needs in-house or by collaborating with peers from other institutions. Vendor solutions might not address the problem adequately or even at all, or they might be too expensive or too restrictive in terms of licensing. In an open source community, a “coalition of the eager” might define a problem and sketch a framework for a solution. Project leaders would then frame specific parameters for the project, how the work should be governed, how the workload might be shared, how costs would be divided, what risks might be involved and how they would be mitigated, and how the project could best be maintained over time. In some cases, an individual institution will adopt an open source solution and then join the development community by submitting issues, fixing software bugs, and suggesting ideas for development. As they become more engaged in the community, institutions may contribute code to existing features or perhaps develop a new tool or module. open source projects are usually emergent in nature rather than planned and typically grow organically to address a given need.

3 Who’s doing it?

open source projects vary greatly in scale. Some are driven by individuals creating a specific application or “widget.” Others are major initiatives developed by institutions, companies, and consortia. Colleges and universities have long used open source code in applications such as Apache web servers and CAS authentication. Other examples frequently found in higher education include Linux, Drupal, Wordpress, MySQL, Postgresql, and Mozilla. Opencast, Tsugi, and uPortal offer open source solutions for teaching and learning, while platforms such as Moodle, Kuali, and Sakai provide solutions for course management and financial systems. Companies including Facebook, Google, IBM, HP, Microsoft, and Oracle often incorporate open source code into solutions they sell. Some open source development takes place under the aegis of well-established consortia or communities, such as the Apereo Foundation, DuraSpace, and Teaching Open Source.

4 Why is it significant?

In contrast to proprietary products, open source solutions typically offer more control over features, functionality, maintenance, and costs, with easier pathways to address security vulnerabilities, software bugs, and evolving needs, often using agile development methodologies. Users of open source code can develop software that fits their needs and participate in defining what the solution is and does, rather than trying to adapt to specifications designed by third parties. Open source offers innovative, customizable, cutting-edge solutions with freely visible standards and specifications. open source code is free to purchase and often can be accessed without burdensome procurement processes. Open source does not tie users to vendor constraints or mandated upgrades. Maintenance can be done in-house, collaboratively with other community members, or with service providers—including cloud providers—on an institution’s schedule. Development time can be faster than for commercial solutions. Transparency in development helps users evaluate code for efficacy and compatibility and discover problems that can be corrected without waiting for a vendor to act. open source implementation can readily act as a reference for others while proprietary code cannot.

5 What are the downsides?

open source projects incur the costs associated with using any software, such as maintaining required hardware and network infrastructure, server/database configuration, general management and maintenance, user support, and staffing and training. If the institution elects to participate in development, it will incur additional costs. Although the ability to alter open source software is a key benefit, sometimes developers disagree or have different goals, which can lead to a split (or a “fork”) in the codebase, resulting in separate, sometimes competing software programs. In addition, some kinds of software offer numerous open source options, while others have none.

6 Where is it going?

Open source is widely used, and its impact is likely to grow. Economic pressures and the expanding scope of services are likely to drive more universities to pursue open source options. Increasingly, too, institutions will find that commercial partners use open source code in certain applications. Colleges and universities will become more comfortable with open source solutions for core functions such as financial management, enterprise resource planning, course and program administration, grants management, and teaching and learning. While practices for standardization and licensing for open source are now well-accepted, questions might arise about license compatibility or patenting around specific licenses.

7 What are the implications for teaching and learning?

Open source gives higher education more control over its application portfolio and can contribute to the next generation digital learning environment. Solutions such as Apereo OAE, CAS, or the Tsugi project have the potential to transform learning management and student support services and enhance student success. open source code is helping expand access to affordable education, and solutions such as Moodle and Sakai are helping advance personalized learning. Opportunities to engage in the development of open source code give students practical experience and practice in project-based management models. Open source projects help faculty and researchers share their work and develop ideas broadly with colleagues around the world and offer new ways for libraries to access and archive digital collections.

Contributions by: Ian Dolphin, Douglas Johnson, Laura Gekeler, Patrick Masson

"7 Things You Should Know About…" is a trademark of EDUCAUSE. "7 Things You Should Know About…Open Source Projects" © 2017 EDUCAUSE and available under a Creative Commons BY-NC-ND 4.0 License.
EDUCAUSE is a nonprofit membership association created to support those who lead, manage, and use information technology to benefit higher education. The EDUCAUSE Learning Initiative is an EDUCAUSE community committed to the advancement of learning through the innovative application of technology. For more information about ELI, please contact us at info@educause.edu.

Image credit: "7Things.png" is a derivative of "1959-xx-xx Educational Cards, Ed-U-Cards A - F", 1959, by Wishbook, via Flickr, and used with permission under Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)."

Categories: FLOSS Research

Public Money? Public Code! 22 Organizations Seek to Improve Public Software Procurement

Thu, 2017-09-14 11:46

Digital services offered and used by public administrations are the critical infrastructure of 21st-century democratic nations. To establish trustworthy systems, government agencies must ensure they have full control over systems at the core of our digital infrastructure. This is rarely the case today due to restrictive software licenses.

Today, 22 organizations are publishing an open letter in which they call for lawmakers to advance legislation requiring publicly financed software developed for the public sector be made available under a Free and Open Source Software license. The initial signatories include CCC, EDRi, Free Software Foundation Europe, KDE, Open Knowledge Foundation Germany, Open Source Business Alliance, Open Source Initiative, The Document Foundation, Wikimedia Germany, as well as several others; they ask individuals and other organization to sign the open letter. The open letter will be sent to candidates for the German Parliament election and, during the coming months, until the 2019 EU parliament elections, to other representatives of the EU and EU member states.

Public institutions spend millions of euros each year on the development of new software tailored to their needs. The procurement choices of the public sector play a significant role in determining which companies are allowed to compete and what software is supported with tax payers' money. Public administrations on all levels frequently have problems sharing code with each other, even if they funded its complete development. Furthermore, without the option for independent third parties to run audits or other security checks on the code, sensible citizen data is at risk.

"We need software that fosters the sharing of good ideas and solutions. Only like this will we be able to improve IT services for people all over Europe. We need software that guarantees freedom of choice, access, and competition. We need software that helps public administrations regain full control of their critical digital infrastructure, allowing them to become and remain independent from a handful of companies," says Matthias Kirschner, President of the Free Software Foundation Europe.

That is why the signatories call on representatives all around Europe to modernize their digital infrastructure to allow other public administrations, companies, or individuals to freely use, study, share and improve applications developed with public money. Thereby providing safeguards for the public administration against being locked down to services from specific companies that use restrictive licences to hinder competition, and ensuring that the source code is accessible so that back doors and security holes can be fixed without depending on only one service provider.

"Over the last few years, more and more companies experienced the benefits of working together on open source software. If even business competitors reuse and share code, then public administrations should be able to as well. If it is public money, it should be public code as well!", says Patrick Masson, General Manager & Director, Open Source Initiative.

Public Money? Public Code! from Free Software Foundation Europe on Vimeo.

Initial Signatories:

Associação Ensino Livre | Associação Nacional para o Software Livre (ANSOL) | Chaos Computer Club (CCC) | D3-Defesa dos Direitos Digitais | Dyne.org Foundation | European Digital Rights (EDRi) | Free Software Foundation Europe (FSFE) | HackYourPhD | KDE | Linux User Group Of Slovenia (LUGOS) | Linuxwochen | Modern Poland Foundation | Open Knowledge Foundation Deutschland | Open Software Business Alliance | Open Source Initiative (OSI | Software Liberty Association Taiwan | The Document Foundation | Wikimedia Germany | Xnet | digitalcourage | ePaństwo | quintessenz
Categories: FLOSS Research

SF Open Source Voting - September 2017 Update / Newsletter

Sun, 2017-09-10 13:03

This update has an important and urgent call to action to help defend elections in California. Stop AB 840, the last-minute change that would weaken California election security at a critical time instead of strengthening it. Can you spare a moment to help?

Retweet this...

Call your Calif. Assembly & Senate reps Monday: ask them to #ProtectElections, vote NO on last-min #AB840 changes: https://t.co/rS6ht4NG3U

— Chris Jerdonek (@cjerdonek) September 10, 2017

Disclaimer: while Chris Jerdonek is a member (and President) of the San Francisco Elections Commission, he provides this update as a member of the public and not as a Commissioner.

TABLE OF CONTENTS
  1. SF's open source voting project in SF Chronicle!
  2. Planning Phase RFP update
  3. SF Open Source Voting Technical Advisory Committee (OSVTAC) update
  4. Spotlight: Colorado's Open Source Election-Auditing project
  5. URGENT ACTION: Stop AB 840! Save election security in California!
1. SF's open source voting project in SF Chronicle!

The SF Chronicle published a great article on San Francisco's open source voting project last week. If you can't read the article because of a paywall, it might work to click through the following tweet using Twitter's mobile app.

2. Planning Phase RFP update

The consulting firm Slalom was selected as the winning bidder on San Francisco's RFP for the open source voting project assessment & planning phase: Congratulations, Slalom! Once the contract is finalized, all three RFP bids should become public (both Slalom's bid and the two non-selected bids).

3. SF Open Source Voting Technical Advisory Committee (OSVTAC)

The 5-member, newly formed Open Source Voting System Technical Advisory Committee (OSVTAC) has now held two meetings at SF City Hall, and things are moving along quickly. The committee now has its own website (hosted on GitHub).

At its second meeting, the committee approved the first iteration of its document of recommendations for the open source voting project. You can read the document online. Just like the committee's website, the recommendations are also hosted on GitHub. The recommendations are being developed in a way similar to how open-source software is developed. In addition to conventional methods like email, members of the public can also submit comments or suggested wording on GitHub, just like with open-source code. The committee will be able to discuss and vote on these suggestions at monthly meetings.

One key difference from an open source project though is that because of state and local open meeting laws, committee members aren't allowed to collaborate as a group outside of noticed meetings. This approach of soliciting public feedback on GitHub is a bit like how the Whitehouse solicited feedback on its draft source code policy last year.

The committee's next meeting is Thursday, September 21 at 6pm.

4. Spotlight: Colorado's Open Source Election-Auditing project

Another example of open-source election software happening right now for US government elections is the following election-auditing project for the State of Colorado. The company Free & Fair won an RFP that Colorado issued this summer. Colorado wants the software to be open source under the GPLv3 license (or something similar). While the license hasn't been confirmed / added yet, you can still follow along and watch the software being developed right now! Chris submitted a couple easy contributions (aka "pull requests") just to see what would happen (and also for fun!).

5. URGENT ACTION: Stop AB 840! Save election security in California!

This week (the week starting Sept 11), the California Legislature is on the verge of passing a terrible bill for election integrity and security. It is called AB 840

.

We need to act now because the California Legislature has only one week left in session. Sept. 15 is the last day. There is so little time because the bill was changed at the last minute, without ever getting a public hearing.

In brief, the bill would remove the legal requirement that all computer-counted ballots have to be subject to the random manual audit after each election (what the California Elections Code calls the "1 percent manual tally"). This is a hard-fought requirement that has been in place for over 10 years. Under the new wording, 30-40% or more of all ballots would be exempted from this requirement. This includes all provisional ballots and all vote-by-mail ballots arriving after Election Day. These ballots would create a huge target for hackers. At a time when election hacking is on the rise, the bill does exactly the opposite of what California should be doing to protect the integrity of the vote.

The change is being pushed by California Secretary of State Alex Padilla and CACEO (the association of county registrars). It was added at the last-minute on August 24 without any public hearings. This was long after the California Assembly passed the bill, and after the Assembly and Senate Elections Committees passed the bill without this wording.

How does this bill relate to open source voting? The security of an open source voting system depends not just on software, but also on the processes around the election. Even if you have paper ballots and open source software, computer hardware can be infected with malicious code to change how votes are counted. Random manual audits checking the computer counts against the original paper ballots are the last defense we have to protect against this.

This isn't just about San Francisco. California state government depends on all counties having secure elections.

There is only one week left. The California State Senate will likely vote on the bill this Monday, Sept. 11, and the Assembly could vote on it Wednesday or Thursday. Please contact your Assembly and Senate representatives and tell them to vote NO on AB 840. Our elections depend on it. For more details on how you can help, see this page: https://countedascast.org/stopab840/

More AB 840 Background

For people who want even more nitty-gritty details, here is more background: In terms of wording, the bill changes the 1% manual tally requirement from "ballots" to "ballots canvassed in the semifinal official canvass." What is the "semifinal official canvass" exactly? It is essentially the "election night" totals. In other words, if this bill passes, there will be no legal requirement that ballots counted after election day by computer be audited. All of these ballots will be exempted from the manual audit. For example, with this bill, malicious code could simply wait until Thursday to "turn on," and any vote tampering would go undetected. Also, even if registrars used their discretion to add more, it would be too late to be effective because the random selection will already have taken place! The malicious code could just "turn on" for precincts that weren't selected.

Why are Secretary of State Alex Padilla and the County Registrars pushing for this change? In 2016, a citizen sued San Diego County Registrar Michael Vu for not including all ballots in the audit. The judge ruled that late vote-by-mail ballots had to be included in the audit, so the citizen won. You can read more in this newspaper article about it.<?p?>

The case is now being appealed. Now, instead of helping counties like San Diego fix their practices and come up with a process to include all ballots, they're trying to weaken the law and remove the requirement. In other words, Vu's past practices would become legal with the change. That is what the AB 840 changes are about. It would make the case against Vu moot. It would also protect other county registrars that choose not to include all their ballots in the audit, instead of protecting voters' ballots and elections.

Here are a couple other recent online pieces about AB 840:

The text of this article was written and provided to the OSI by Chris Jerdonek

Image credit: "SFUpdate.png" is a derivative of "Solitude", 2011, by Mortimer62, via Flickr, and used with permission under Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0). "

Categories: FLOSS Research

The Faces of Open Source: Jim Wright

Fri, 2017-09-08 08:32

Jim Wright features in the sixth episode of Shane Martin Coughlan's, "The Faces of Open Source Law." about open source, law and how our community is evolving. Interviews were shot during breaks at the FSFE Legal Network 'Legal and Licensing Workshop' in Barcelona during April 2017. Thanks to everyone who made it happen!

Jim is a powerhouse of knowledge in open source. He is fully versed in technical issues and deeply experienced in legal matters, both visible immediately in his quick, easy and comprehensive commentary around virtually any open source-related subject. Our discussion was framed by the same three questions as all the others in season one: how did he enter open source? what was the most interesting thing he observed? what did he think we should keep our eyes open for in the next 12 to 24 months? What stood out is perhaps how Jim tied his answers to the longer history of open source itself, and framed his answers in the content of our 20 plus year evolution as a community.

One thing that Jim’s interview highlighted was that there was plenty of scope for deeper, more comprehensive interviews as we explored open source law, and he helped set the tone that would see a decision to shoot long-form interviews in the forthcoming series two.

Other episodes:

"Jim Wright - The Faces of Open Source Law - Season 1 - Episode 6" is licensed under Creative Commons Attribution license.

Categories: FLOSS Research

OpenProject Foundation Joins Open Source Initiative

Tue, 2017-09-05 12:03

Open source project management software, with global user base, extends commitment to collaborative open source software development through OSI Affiliate Membership.

PALO ALTO, Calif. - Sept. 05, 2017 - The Open Source Initiative® (OSI), the founding organization of the open source software movement, announced that the OpenProject Foundation has joined the global non-profit as an Affiliate Member. OpenProject joins a who's who of global open source projects and foundations in support of software freedom, including Drupal Association, Eclipse Foundation, Linux Foundation, Mozilla Foundation, Wordpress Foundation, Wikimedia, and many more. The OSI Affiliate Member Program allows any non-profit community, organization or institution—unequivocally independent groups with a clear commitment to open source—to join the OSI in support of its mission to educate about and advocate for the benefits of open source software and to build bridges among different constituencies in the open source community.

"The Open Source Initiative provides a strong global platform aimed at promoting and strengthening open source software,” says Birthe Lindenthal, Chairperson of the OpenProject Foundation. “At OpenProject we share this commitment to open source software and are looking forward to supporting OSI's mission."

OpenProject is an open source project management software with a large international user base. Licensed under the GPLv3, OpenProject was first released in 2012 and is used by many small, medium and large sized companies as well as individual users who value the benefits of open source. OpenProject aims to become the leading open source project management software and focuses, in particular, on creating a great user experience, and features that support the entire project life cycle, through the use of state-of-the-art technology. Developed as a fork of Redmine and Chiliproject, OpenProject initially focused on software development projects, but has since implemented many functionalities that enable traditional project management outside of the scope of software projects as well.

“OpenProject’s clear commitment to, not only open source software and development, but the ‘open source ethos’ makes this an exciting opportunity for us at the OSI,” said Patrick Masson, General Manager and Director at the Open Source Initiative. “The OpenProject Foundation serves as a model for other emerging open source software projects on how to organize, govern, and develop, ensuring the project and community are directly involved, while also protected so that code and contributions remain open despite the involvement of any individual developers or companies.”

Robin Wagner, Product Manager at OpenProject added, "At OpenProject we aim to develop the leading open source project management software, based on our shared values of protecting and promoting open source software. The Open Source Initiative is the perfect fit for us. We are honored to become an OSI Affiliate Member."

About OpenProject

Driven and inspired by our users, our community and by the utilization of state of the art technology, the OpenProject Foundation (OPF) is incorporated as a membership-based, non-profit organization. Although registered in Berlin, Germany, the OPF is designated for the global OpenProject community. The foundation supports and guides the software project, the community and its growth, ensuring that the OpenProject platform continues to exist beyond the participation of individual members or companies. For more information, please visit: https://www.openproject.org/openproject-foundation/.

About the Open Source Initiative

Founded in 1998, the Open Source Initiative (OSI) protects and promotes open source software, development and communities, championing software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition, and preventing abuse of the ideals and ethos inherent to the open source movement. The OSI is a California public benefit corporation, with 501(c)(3) tax-exempt status. For more information about the OSI, or to learn how to become a sponsor, please visit: https://opensource.org/affiliates.

Categories: FLOSS Research

Rocket.Chat Extends Support to Open Source Initiative and Community

Tue, 2017-08-29 13:45

OSI welcomes Rocket.Chat as newest Corporate Sponsor: support not only provides financial aid, but extends infrastructure and services to larger open source software advocacy community.

PALO ALTO, Calif. - Aug. 29, 2017 -- The Open Source Initiative (OSI), the founding organization of the open source software movement, announced Rocket.Chat has joined the global non-profit as a Premium Corporate Sponsor. Rocket.Chat joins Craigslist Foundation, Facebook, Github, Google, Heptio, HPE, IBM, USB Direct, and many more sponsors, supporters and members committed to increasing awareness of open source software, and participation within the innovative communities that enable its continued advancement.

"We're very excited to announce Rocket.Chat's sponsorship, not only because of their generous financial support, but also because they'll be providing access to the Rocket.Chat platform itself in support of our Incubator Projects and Working Groups," said Patrick Masson, OSI General Manager. "The OSI community is highly distributed, and access to a collaboration platform like Rocket.Chat will help our community organize, co-create and manage the very important work underway to increase the understanding and adoption of open source software."

The OSI provides opportunities and resources—web hosting, wikis, mailing lists, etc.—for open source advocates to self-organize around affinity issues and projects. These "Incubator Projects" are dedicated to addressing a specific need of, and for, the open source community in line with the OSI's mission of education and advocacy while building bridges among different constituencies. Incubator projects focus on the creation of resources for open source communities, development practices, licensing or any other non-code aspect of the open source ecosystem. With the addition of Rocket.Chat as a Premium Corporate Sponsor, another valuable tool has been added to the resources the OSI can provide Incubator Projects to help advance the open source movement.

About Rocket.Chat
Rocket.Chat is the leading open source team communication platform. A free Slack alternative to take back control of your data, save time and increase productivity. Communicate anywhere with our web, embeddable, desktop and mobile clients. Message, screenshare and conduct audio and video conferences in private, public and guest channels. Secure user roles with our advanced access control tools. Embed chat in your web and mobile applications with LiveChat and transform your team chat into a single communication platform for messaging, customer support and lead generation. Make Rocket.Chat your own with our open source community, partnership integrations, plugins and powerful APIs.

About the Open Source Initiative
Founded in 1998, the Open Source Initiative (OSI) protects and promotes open source software, development and communities, championing software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition, and preventing abuse of the ideals and ethos inherent to the open source movement. The OSI is a California public benefit corporation, with 501(c)(3) tax-exempt status. For more information about the OSI, or to learn how to become a sponsor, please visit: http://opensource.org/sponosrs.

Contact
Italo VIgnoli
OSI Director & Marketing/Communications Chair

Categories: FLOSS Research

The Faces of Open Source: Till Jaeger

Mon, 2017-08-28 15:51

Dr. Till Jaeger features in the fifth episode of Shane Martin Coughlan's, "The Faces of Open Source Law." The series was shot during breaks at the FSFE Legal Network 'Legal and Licensing Workshop' in Barcelona during April 2017, and is provided here to promote greater understanding of how the law and open source projects and communities are interacting and evolving.

Shane's series explores the history of open source software from the perspective of the people who contributed to its development, not just the technologies, but importantly the legal aspects that are core to open source's success. Several interviews include members of the OSI community--some of the folks who have helped the OSI and software movement grow to become the internationally recognized resource it is today.

As in previous episodes, Shane also provides "production notes", offering some of his own insights from the interviews and around the topics discussed.

Enjoy...

Till is one of the original lawyers behind open source license compliance. His work for gpl-violations.org is well-known as is his more recent engagement in the GPL case involving VMware. What is less known is who Till is, how he sees the world, and why he dedicates a lot of time to issues around open technology. Our interview was relatively short but we managed to capture at least a few of these items, and to touch on Till’s larger interests beyond open source. He is, of course, just as well known for contributions to cases around digital citizenship as open source in his native Germany. An exceptionally talented individual who is also an exceptionally nice gentleman.

Other episodes:

"Till Jaeger - The Faces of Open Source Law - Season 1 - Episode 5" is licensed under Creative Commons Attribution license.

Categories: FLOSS Research

How Can Open Source Become User-Centric?

Sun, 2017-08-27 10:55

Including design and UX in a true community project is a challenging matter of balance because of the motivational model behind open source projects.

According to The Cathedral and the Bazaar, the key motivation for participants in open source projects is “scratching their own itch.” One consequence of this is co-ordination of contributions to support user-centric design is inherently an optional extra in a true open source project with multiple independent participants. We all wish there was a way to get genuine user experience quality as a key dynamic of open source projects. But there are two big reasons that is challenging.

First, individual users truly don’t know what all users want.

  • To be clear, I am not repeating the trope that “users don’t know what they want”.
  • Each user knows what they want, and those with the personality profile that allows them to express their desires articulately in public can often make a compelling case for their own needs.
  • But an overall evaluation of “what users want” is perilously difficult to establish, even for corporations which can eliminate large numbers of voices with the requirement that payment must be made to have a qualifying opinion. Corporations employ Product Managers who use market research and personal experience to guide development. It’s a well understood job, but even with skilled product managers a proprietary project can miss the mind of the market.
  • User voting is not the answer, as anyone who has seen it in action in Bugzilla can testify. I’m not convinced that user-funded bounties help identify broad user needs either, although they offer a useful avenue for funding some open source.
  • All the same it is very common indeed, especially in end-user software, for users to show up demanding a feature be implemented or changed. I have often seen community members struggle to remain courteous to rude, entitled freeloaders demanding things they want from people they have never met and have no intention of thanking, let alone paying.
  • Instead, users need skilled advocates speaking on their behalf, prioritizing features based on utility, demand and practicality and working with developers to advance the user experience offered by the software.
  • They need to do so from a base of merit-earned status and not appointment.
  • What I crave for open source software is thus a user experience centric approach, not a user-centric approach, and they are dramatically different.
  • But that requires the appointment of a skilled user advocate, not the ad-hoc voices of millions of individuals or a self-selecting subset with type A personalities.

Second, developers in open source free software projects don’t take orders.

  • That’s just a consequence of the model. An open source project arises where the intrinsic interests of many people overlap. The overlap does not make their intrinsic interests merge; it simply creates an area of their respective lives where they collaborate with others, or use the work of others with whom they have no other relationship.
  • The lack of any other relationship is what makes software freedom so important. By guaranteeing that every individual can use, improve and share the software without reference to any other person or entity, we ensure each person is free to meet their own needs without interference.
  • The corollary of that freedom is a lack of authority relationship. Two users who use the software in different ways are unable to force each other to change they way they use the software; if they want interoperable behavior they need to negotiate it. Two developers who earn their living from the software in different ways are unable to force each other to implement a feature that serves their needs. Instead they must implement the code they need and negotiate its inclusion with others. Finally a user wanting a feature implemented cannot demand a developer implement it. They might make it appeal to a developer, perhaps by paying them outside the scope of the project. But there is no basis for an authority relationship.
  • This places the UX expert in an invidious position. A UX outlook is inherently the synthesis of user experiences, so represents no individual in its entirety. UX also involves directing others in how to shape their code, in an environment where power relationships are expressly excluded.
  • Further, in a collaborative project, every participant pays their own way (rather than looking to the project for pay) and meets their own needs (rather than directing or paying the project to do so).
  • A UX expert and/or “product manager” is also very unlikely to have an external motivation for their involvement. As a consequence, it’s quite unlikely that one of the collaborators coming to the project will be a UX practitioner and if they are, their external motivation for doing so will probably be a concern for the project.

That’s not to say projects are ignoring UX. Two examples:

  1. Mozilla spends a significant sum on UX and has been able to elevate respect for UX so that it is a developer priority (although of course Mozilla is special).
  2. TDF have recently decided to spend donated funds to retain a UX expert to support the LibreOffice developers (who are already supported by a good design team) and are in the process of exploring how best to help him interact with the developers, who are not under the majority control of any entity.

Self-reliance arising from motivations and rewards external to the project is a fundamental part of the open source model. While some are frustrated that the developers get to call all the shots, to challenge their power over the future of the project is to Quixotically confront a natural force that arises from inherent self-reliance and is doomed to frustration. Trying to shame developers into accepting your authority has a poor track record of success.

So if you would like to switch to a user-centric approach for open source development, you will need to answer the two questions that arise from the analysis above:

  1. Which users will be at the centre, how do they get there, why are they the ones who should be there and who is representing them?
  2. What will motivate the people who actually make stuff – developers, designers, documenters – to do the things they ask for.

We need to explore ways to build motivations for UX practitioners to join collaborative communities and mechanisms for their contributions to not violate the natural dynamics arising from the absence of authority relationships. Mozilla has one approach, and TDF another. Maybe others have approaches they can share and from which we can all learn? Let us know below.

This article was originally published in Meshed Insights, and was made possible by Patreon patrons.

Image credit: "userCentric.jpg" is a derivative of "Computer Expert", 2015, by Karen Baijens, via Flickr, and used with permission under Creative Commons' Attribution 2.0 Generic (CC BY 2.0). "

Categories: FLOSS Research

The Faces of Open Source: Mark Radcliffe

Mon, 2017-08-21 22:52

In this fourth episode of Shane Martin Coughlan's, "The Faces of Open Source Law," we continue our introductions to the vibrant open source community, through discussions with some of it's most active contributors.

Shane's series may focus on legal issues, but through his discussions, you'll also find a wealth of information related to broader topics related to development, community and contributions. We're also very lucky to include in this series interviews, some of the folks who have helped the OSI grow to become the internationally recognized organization it is today. This week is no different with an interview with the OSI's legal counsel.

As in previous episodes, Shane provides "production notes", offering his own insights from the interviews.

Enjoy...

Mark is someone that is known to everyone. He has been involved in open source law since it became commercially viable and he has insight into market adoption from startups through to multinationals. Mark also has been involved in helping NGOs such as Open Source Initiative, but in our interview I wanted to stick closely to the commercial side of things, for the simple reason that his ability to express market concerns is second to none.

It is noteworthy that in shooting this interview I already had the germ of season two of Faces of Open Source Law in my mind, I was thinking it would be using long-form interviews, and I wanted to have Mark as one of the interview subjects. This meant our season one interview is more closely focused than the others in the series, and in some ways it is biased towards setting the scene for a much longer conversational discussion in due course.

Other episodes:

"Mark Radcliffe - The Faces of Open Source Law - Season 1 - Episode 4" is licensed under Creative Commons Attribution license.

Categories: FLOSS Research

SerenataFlowers.com and Hipper.com Extend Support to Open Source through OSI Sponsorship

Wed, 2017-08-16 12:32

Open source adoption continues to grow as companies seek not only higher quality software, lower costs, and an end to predatory vendor lock-in, but also leverage the power of community investment and collective intellect to drive innovation.

PALO ALTO, Calif. - Aug. 16, 2017 -- Today the Open Source Initiative® (OSI), the global non-profit formed to educate about and advocate for the benefits of open source software and communities, is pleased to announce corporate sponsorships from SerenataFlowers.com and its sister company Hipper.com. SerenataFlowers.com recently extended their corporate giving program to recognize open source software projects and the communities that develop it, particularly those projects used to enable their own business, through financial donations and employee development time. The OSI joins other beneficiaries including, PG Routing, Creative Commons, Piwik, Selenium, Posgreslq and others.

"The support of SerenataFlowers.com is extremely satisfying for us at the OSI. Many mistakenly believe that contributions—both financial and technical—are primarily made by companies working within the software industry, you know, developers not florists," said Patrick Masson, General Manager at the OSI. "However SerenataFlowers.com highlights that today, all companies are software companies and thus all companies can benefit greatly from adopting open source software and working with the collaborative communities that support it."

SerenataFlowers.com's Managing Director, Martin Johansson, emphasized the company's investment, "We actively use a large number of open source software in our website front-end and back-end development. Examples include, Snowplow Analytics, Metabase, Joomla, foundation framerwork, MySQL, and many others." Johansson added, "Open source software is one of the cornerstones upon which our business is built. We believe open source software is both more secure and more efficient than their closed-source counterparts and we are actively looking to replace as many closed-source technologies for open source equivalent technology."

Corporate sponsors like SerenataFlowers.com provides the OSI with funds to support a variety of unique initiatives to help promote and protect open source software and the communities that develop it. The OSI understands corporate use of, and participation in open source development is vital to overall success. The OSI's corporate sponsorship program provide a open and transparent mechanism to allow companies to show support for open source software, its development, and the activities of the OSI. Donations allow the organization to continue our mission of education, advocacy, community building...and, of course, maintain our license certification programs.

Corporate sponsorship also provides opportunities—and resources—to interested contributors to self-organize around affinity issues and projects dedicated to addressing specific needs of, and for, the open source community. These, "Incubator Projects" focus on the creation of tools and services for open source communities, development practices, licensing or any other non-code aspect of the open source ecosystem.

About SerenataFlowers.com
SerenataFlowers.com is an independent online florist that specializes in the design and delivery of fresh, superior-quality floral arrangements. Founded in 2003, the company has blossomed to become the largest independent online flower retailer in the UK, picking up plaudits for its exemplary Web site and unique customer experience -- and making some very loyal flower-loving friends in the process. SerenataFlowers.com are the equivalent of A-list celebrities: gorgeous, desirable and boasting a longer shelf life than their contemporaries. Sourced from the finest growers, the flowers are groomed with fastidious care, fashioned to perfection and elegantly transported to their destination in the shortest possible time. For more information about SerenataFlowers.com, visit https://www.serenataflowers.com/.

About the Open Source Initiative
Founded in 1998, the Open Source Initiative protects and promotes open source by providing a foundation for community success. It champions open source in society through education, infrastructure and collaboration. The (OSI) is a California public benefit corporation, with 501(c)(3) tax-exempt status. For more information about the OSI, or to learn how to become a Corporate Sponsor, please visit: https://opensource.org/sponsors.

Contacts
Lucia Polla
SerenataFlowers.com
lucia@serenataflowers.com

Italo Vignoli
Open Source Initiative
italo@opensource.org
Categories: FLOSS Research

The Faces of Open Source: Kate Stewart

Tue, 2017-08-15 10:45


This is the third episode from the series in Shane Martin Coughlan's, "The Faces of Open Source Law," that puts a face to the vibrant open source community, and the fascinating discussions happening within it. This series of interviews focuses on issues related to law affecting open source projects and communities—copyright, licensing, patents, foundations, governance, etc.—and includes interviews with several current and former OSI Board Directors.

In addition, Shane provides "production notes" for each of the videos (presented below), offering his own insights from the interviews

Enjoy...

Kate is one of the faces you see at practically every significant event with open source governance discussions and she is one of the unsung heroes of open source maturity. From her work in building out SPDX to her role in the Linux Foundation Open Compliance Program, she has a hand in producing and socializing a wealth of knowledge and solutions.

In our interview I wanted to explore motivations rather than discuss a list of activities. Because Kate is behind so many projects, and many of these projects touch on issues that may be regarded as daunting—such a developer compliance training—I felt that pulling back to the big picture of *why* she is contributing would be more useful than precisely *what* she is contributing.

The main point that I wanted to convey in this interview, and indeed with the series as a whole, is that the people behind the projects are great. They are all approachable, articulate and helpful people motivated to promote collaborate solutions to shared challenges.

Other episodes:

"Kate Stewart - The Faces of Open Source Law - Season 1 - Episode 3" is licensed under Creative Commons Attribution license.

Categories: FLOSS Research

Former CIA Dir. Woolsey joins OSI member NAVO in movement to open source elections

Mon, 2017-08-14 22:31

Former CIA Director and U.S. Ambassador James Woolsey recently issued a New York Times op/ed piece with open source stalwart, GNU Bash creator, and technology lead for OSI Affiliate Member NAVO/CAVO, Brian Fox, to call on politicians to expedite efforts toward open source election systems. Director Woolsey was blunt about the need for Microsoft and others to cease and desist lobbying efforts against the open source voting community and commended the open source momentum toward securing the elections.

NAVO / CAVO Secretary Brent Turner responded to the New York Times article with appreciation for Amb. Woolsey stating,"We are pleased that this is hitting the main stream media and look forward to helping to facilitate the transition from the at-risk proprietary code voting systems to the open source model more capable of protecting the national security".

Turner and Woolsey, along with Hollywood notables, are currently involved in filming a documentary "The Real Activist", exposing the underbelly of the election integrity world and highlighting the struggle for GPL open source paper ballot election systems.

Categories: FLOSS Research

7 Rules For Engaging Communities On Legal Matters

Fri, 2017-08-11 11:44

Having watched a fair number of people attempting to engage both the Open Source Initiative’s licensing evaluation community and the Apache Software Foundation’s legal affairs committee, here are some hints and tips for succeeding when your turn comes to conduct a discussion over legal terms with an open source community.

When you need to discuss a license, a legal document like a CLA or a governance rule with an open source community, what’s the best approach to take?

  1. No Proxies
    First and foremost, make sure the person conducting the conversation is both qualified and empowered. Don’t send proxies; they simply frustrate the community who quickly work out that your representative is always playing the second-hand car salesman and going to the back room to ask for a deal. Legal discussions obviously will involve a team at your company, probably including product management, engineering and in-house counsel. But your representative needs to be able to hold the conversation themselves and not keep delivering cut & paste quotes from anonymous personae behind the curtain.
  2. Multilaterality
    An open source community reaches a hard-won consensus on the certainties they need in order to collaborate safely. That consensus gets embodied in their governance and especially in the open source license they use. So when you come with a new proposal, it’s not like a normal business deal. Those are bilateral negotiations, trading the freedoms of the two parties to create a peace treaty that’s an optimal compromise. In this discussion you are just one of many, many parties and you need to explain why your proposal is good for everyone. The culture is different here too – don’t assume anyone shares your objectives. Negotiating multilateral change is inherently slow, so don’t come with a deadline. And whatever you do, don’t suggest changes to the open source license!
  3. Study First
    The existing consensus and process exists for a reason. You should understand the reason for each element, preferably along with the history of how it arose, before suggesting changes to it. That way you can couch your proposals in the context of further evolution, as well as avoid being schooled in community history, something that wastes community bandwidth and reduces your chances of effectiveness. Read back in the mailing list and ask your developer colleagues for history and context.
  4. Transparency
    Open source developers use a process of iterative, incremental change. Even if a big change is needed, it will almost always be delivered as a sequence of smaller, well-explained or self-evidently correct changes so that everyone can follow along and buy in to the improvement. The same is true of your proposed change. Don’t show up with a new contributor agreement or a modified license and expect everyone to trust that you’re experts so it must all be good. You need to provide a “red-line” (the legal document equivalent of a diff), document each change and provide a justification that admits any community impact and justifies it. If you need a thing to be so for your own benefit, admit it rather than hoping no-one will notice.
  5. Humility
    So you are a hot-shot lawyer and you think the mailing list comprises all programmers. It’s clear to you that they’ll lack the experience to have a discussion, so you either send a proxy you think is their equal, dumb it all down or propose having a 1:1 discussion with the community’s chosen lawyer. Sorry to say you are so, so wrong on all counts. Since the community’s policy is a multilateral consensus, there is a really good chance they know why they settled on what they have now. There will be some people on the list with excellent domain-specific knowledge, likely to be better than yours. And that 1:1 thing is the ultimate insult, like asking if there is an adult you can speak with.
  6. Don’t back-channel
    There may well be a leadership body of some kind. Maybe you know the boss at the company where the VP Legal works. Perhaps you know the community’s General Counsel. While asking for hints on how to navigate the process may be OK in some circumstances, trying to conduct a back-channel discussion or negotiation with the expectation of influencing or even determining the outcome can blow back badly. You may eventually be invited for a 1:1 discussion, but you should never demand or expect it.
  7. Become a Member
    If you do everything right, chances are that the community will respect you for it. Stick around. Build your reputation as a calm, wise contributor. Help others when they show up and make the mistakes you made (or avoided!) As a trusted participant in the “$-legal” mailing list community, you are a real asset to both the project and your employer. Keep contributing and some projects will eventually offer you a role in their governance process.

This article was originally published in Meshed Insights, and was made possible by Patreon patrons.

Image credit: "7Rules.jpeg" is a derivative of "Silhouettes, Against, Nonconformist, Anti, Anders" via Max Pixel, used under CC0 Public Domain. "7Rules.jpeg" is licensed under CC BY 4.0 by The Open Source Initiative

Categories: FLOSS Research

The Faces of Open Source: Luis Villa

Tue, 2017-08-08 17:35


This is the second episode from the series, "The Faces of Open Source Law," by Shane Martin Coughlan. The series puts a face to the vibrant open source community, and the fascinating discussions happening within it, through a series of interviews that we'll be sharing here. This first "season" focuses on issues related to law (copyright, licensing, patents, foundations, governance, etc.) and includes interviews with several current and former OSI Board Directors.

In addition, Shane has graciously offered his own insights from the interviews, which we've included below.

Enjoy...

Luis Villa - The Faces of Open Source Law - Season 1 - Episode 2

There are a ton of people who have contributed to pushing forward knowledge around open source and more generally open culture. One of the names that keeps cropping up is Luis Villa, a gentleman that some recognize from OSI, some from Wikimedia, and some from his contributions to inter-community legal and social discourse. I sat down with Luis in the second episode of “The Faces of Open Source Law” to touch on the breadth of how the concepts of “use, study, share and improve” have touched on so many aspects of innovation in modern life.

One of Luis’s strengths is his ability to articulate immensely complex ideas in a simple, approachable manner. Another is to be cognizant of how so many moving parts of open source, open data and open culture are evolving. We opened “The Faces of Open Source Law” with a slightly technical figure in Armijn Hemel. With Luis we pulled back further towards the politics and law, and set the scene for digging into more legal or corporate areas as the series progressed.

I have to give kudos to Luis for providing one of our best interviews without any rehearsal. We simply sat down, started talking, and flowed into some of the big issues. Each episode is only a few minutes long, inherently limiting what we can cover, but we always ended with a “what should people watch out for in the next 12 to 24 months?” Luis set a great tone with his answer.

Other episodes

"Luis Villa - The Faces of Open Source Law - Season 1 - Episode 2" is licensed under Creative Commons Attribution license.

Categories: FLOSS Research

Give Generously! Seven Ways To Help Open Source

Sat, 2017-08-05 16:20


Should you donate money to the open source projects you use? Or is there a better way to help?

Your business most likely depends on open source software. But are you playing your part to make sure it will still be there in the future? For that to happen, the projects where it is both maintained and improved need to flourish.

How can you contribute to that goal? The first thought most of us have — donate money — is unlikely to be the best way to support the open source projects that are most important to you. While proprietary software companies want your money in huge quantities to pay their shareholders, executives and staff, in open source communities most of the people who develop the code are paid elsewhere. As a consequence, there’s only a modest need for cash and a little goes a long way.

So what is the best way to support open source if communities don’t primarily need your money? Here are seven ways your company can support and strengthen the open source projects you depend on.

1. Buy from community members

Open source communities typically comprise many of the people whose business interests most depend on the sale of services and extensions of the project. They are trainers, contract developers, support companies, integrators and more. The very best way most of us can support open source is by trading with those people and businesses.

So when you buy training, or service level agreements or contract development, check your supplier is an active community member. Ask them about their commits to the project, their attendance at community conferences, their participation in governance. Some communities even have a way for members to prove their participation, such as official membership or even certification. There are a surprising number of companies — especially offering level 1 and 2 support services — which don’t meaningfully participate in the community. In many ways, those companies are the real freeloaders and it’s better not to encourage their existence.

2. Promote the project

Open source projects aren’t like commercial products. There’s no-one with a vested interest in publishing marketing information about them, so it’s easy to believe they are of marginal interest if you just look at the press where content is driven by marketing actions. The very fact your company uses a particular set of open source software is interesting, and sharing the details in public is valuable.

So don’t keep it a secret. Add information to your web site about the open source projects you use and how you use them. Encourage staff to contribute articles and case studies for publication. If you make you open source usage public, you’ll discover other people using the same software who can also be encouraged to share their experiences. In fact there’s a word for them: community.

3. Participate in the community

As a user of an open source project, you have a role to play in the community. One direct and valuable way to support the projects upon which you depend is to participate. As simple an act as asking your staff to attend a local meet-up or even a regional conference helps. These events build the community and in some cases are the main source of funds to pay for the small staff and infrastructure costs for a community. Participating does not have to mean directly contributing to the code and documentation; just showing up is of value. Of course, you can go further and contribute in a more concrete way.

4. Contribute to the project

Obviously this is going to help! But you may be surprised by how welcome even small contributions can be. An open source project is the overlap of the interests of many participants. Not every community participant is involved to the same degree; in fact a community has a “long tail” participation curve, with many participants making smaller contributions and only a few making large ones. Your contributions will be welcome, no matter how small.

As a user of open source software, you can contribute bug reports — possibly through the service company you have hired — and even patches to fix defects you’ve found if you’re actively developing in and around the code. One great way to contribute is to offer your own internal how-to documents and implementation case studies. And of course you can make larger contributions of code and new functions.

5. Commission improvements

Perhaps there is a feature you need in the software you’re using. It won’t write itself, and the community is not there to meet your needs; they are mostly there to meet their own. You could complain about it, or you could invest some money in addressing it. You’re probably not the only company with the need.

You might be able to use the approach a group of German and Swiss public administrations are using to address their need for LibreOffice to have better interoperability with Microsoft Office. They’ve teamed together through the Open Source Business Alliance to commission community core developers to do the work they need and contribute them to the community. The result is that LibreOffice now has much better capabilities in both reading and writing Microsoft’s OOXML format.

6. Hire committers

You depend on the project. Why not hire the developers who created it or who keep it running? You can make a significant contribution to a community by directly employing core developers of the software that you most need tuned or customised to your business needs. When you hire them, make sure you’ve left enough room in their lives to continue to meet their community commitments.

Hiring core community developers is a great way to ensure your company’s needs are met! You can also participate in the governance of the community. Help with the administration, make staff available for infrastructure or marketing work, stand in Board elections.

7. Make cash donations

OK, I said not to do this — but I meant as an only or first step. As a community member, you do have a role to play helping pay a share of the the bills. This might include the cost of the infrastructure and the sysadmins who run it or perhaps the cost of an executive director and a small staff. It is very unlikely to pay for the actual development of the code itself — that’s the community’s responsibility. You could become a sponsor, or even an advisory board member, as a way to channel funds into the shared coffers of the community.

There are other ways to support open source, but these seven steps provide a path for many companies to ensure that the software running the business remains available, debugged and innovative over time. It needn’t cost much money, and most of these steps flow directly out of your business needs and practices. Give it a try!

This article was originally published in InfoWorld in September 2013. A revised version appeared on "Meshed Insights" and was made possible by Patreon patrons.
Image credit: "Bridge" is a derivative of "The Little Bay Bridges span the mouth of Little Bay, seen from Dover Point." by JayDuck (own work), used under CC BY-SA 3.0 via Wikipedia. "Bridge" is licensed under CC BY-SA 3.0 by The Open Source Initiative

Categories: FLOSS Research

Sharing "The Faces of Open Source"

Tue, 2017-08-01 09:42


A few weeks ago we learned about some great work underway by Shane Martin Coughlan: putting a face to the vibrant open source community, and the fascinating discussions happening within it, through a series of interviews—we thought we'd share them here in a new series.

"I've been enjoying 'The Faces of Open Source Law.' It's excellent to hear the voices and see the faces behind the famous names in this space as they are usually detached far behind a screen. I feel a real connection to them.”
— Chris Lamb, Debian Project Leader

Shane's first series, focused on open source law, included several current and former OSI Board Directors--so obviously we were interested in featuring those--yet, the conversations with others working in and with open source software proved just as valuable: personal motivations and interests that drive participation, insights on licenses and licensing, opinions on current legal issues, and even community related activities that help foster collaboration and build projects. Shane was kind enough to share his work and we're very pleased to post it here. Shane will also be providing some additional content for us through his "production notes", which offers his thinking behind the topics covered, some insights gleaned from the discussions, and even take-aways for the reader/viewer from his own experiences.

Again, we're very excited to offer these to you here, and thank Shane for all his good work.

Enjoy..

I had the idea for producing a series about the faces of open source law about five years ago. The developers in open source had a lot of events and - compared to the legal people - lots of international exposure. Yet the people driving both communities were fascinating, approachable and generally awesome. So what if we gave the legal people more exposure, tied names and email addresses to real stories, and built a new community bridge? At the time I was pretty busy scaling the Open Invention Network community of patent non-aggression and working on policy issues via OpenForum Europe so I put the idea on my “to-do” list.

Fast forward to 2017 and I had a little more bandwidth, the idea still seemed valid, and a large number of the faces behind open source law were gathering for a conference in Barcelona. On final last day of the event I set up my camera in a quiet(ish) section of the networking zone and sat down between presentations to record the entire season. The egotistical version is that I pre-planned to capture a great series of interviews in one afternoon. The real version is that we had space in the last hours of the last day and I rolled a dice to see what we got. What we got was something pretty special.

First up in “The Faces of Open Source Law" was a figure who has quite literally acted as a bridge between the technical and legal side of open source for many years: Armijn Hemel. He has been involved in extensive community engagement in gpl-violations.org, extensive business engagement as a consultant, and less visible but immensely valuable networking between all types of people and organizations across our field. This is his story.

Armijn Hemel:

"Armijn Hemel - The Faces of Open Source Law - Season 1 - Episode 1" is licensed under Creative Commons Attribution license.

Categories: FLOSS Research

Public Domain Is Not Open Source

Fri, 2017-07-28 08:45


Open Source and Public Domain are frequently confused. Here’s why it’s a mistake to treat the two terms as synonyms.

Plenty of people assume that public domain software must be open source. While it may be free software within your specific context, it is incorrect to treat public domain software as open source or indeed as globally free software. That’s not a legal opinion (I’m not a lawyer so only entitled to layman’s opinions) but rather an observation that an open source user or developer cannot safely include public domain source code in a project.

First let’s look at the two terms and what they mean to individuals.

  • 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.
  • Public Domain” means software (or indeed anything else that could be copyrighted) that is not restricted by copyright. It may be this way because the copyright has expired, or because the person entitled to control the copyright has disclaimed that right. Disclaiming copyright is only possible in some countries, and copyright expiration happens at different times in different jurisdictions (and usually after such a long time as to be irrelevant for software). As a consequence, it’s impossible to make a globally applicable statement that a certain piece of software is in the public domain.

The community goes to great efforts to ensure things called “open source” are under an OSI-approved copyright license even though some regard it as obstructive bureaucracy. Many would prefer to simply say their code is “public domain” but that doesn’t deliver the key benefit open source offers: certainty over the core freedoms of free software. That leaves doubts about there being sufficient permission-in-advance for some collaborators.

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 called “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. That final case comes with some complexities, but they are considered elsewhere.

Public Domain software may come with the rights delivered by those “four freedoms”, but you can’t be sure. It will depend where the software was written, where you are located, who the author is and where the people you are sharing the software with are located. A deployer or developer will need to at very least ask for advice before proceeding, and most likely will need to secure the services of a legal professional with experience in copyright law in each affected country. Even asking the author is unlikely to be conclusive. That’s why public domain software may be free software but is not certain to be.

A solution would be to create a form of words to be used by the author to dedicate something to the public domain. It could simply disclaim ownership for the jurisdictions where that is possible, and then grant a copyright license that has the same practical effect as a public domain dedication for jurisdictions where ownership of copyright can never be disclaimed. Such a formulation has been published by the Creative Commons. They call it “CC0” and it is widely used and well respected.

There’s an issue though; it has not received OSI approval. Many reviewers believe it should, but its authors withdrew it from the approval process during a complex discussion about patent rights and it remains unapproved. The matter has recently been re-opened; lets hope OSI and CC can work together to bring the certainty on which open source thrives. In the mean time, it’s probably safer to use a license like MIT instead.

This article originally appeared on "Meshed Insights" and was made possible by Patreon patrons.
Image credit: "Only Only" is a derivative of "Right & Left Turn Only Arrow Sign" by Linnaea Mallette used under CC0 / Public Domain via PublicDomainPictures.net. "Only Only" is licensed under CC-BY 4.0 by The Open Source Initiative

Categories: FLOSS Research

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